독까의 이야기

요즘 대부분의 웹사이트들은 보안 인증서 (SSL) 적용이 되어 있다. 개인 정보가 등록되어 있는 웹사이트들은 SSL 미적용시 법적으로 처벌을 받게 되어 있다. 


https 프로토콜의 기본 포트는 443 이다. 

443 포트를 다수의 웹사이트가 공유하여 사용하려면, 멀티 인증서 또는 와일드카드 인증서를 적용해야만 했다. 

그러나, IIS 8.0 이상 부터는 동일 아이피에서도 443 포트 다중 사용이 가능하게 되었다. 


https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability


"서버 이름 표시" SNI 가 그것인데, 해당 기능에 대해서 테스트를 진행하도록 하겠다. 



# 1 

SSL 적용 될 웹사이트 생성 


sni1.gunnm.xyz 

sni2.gunnm.xyz




# 2 

발급 된 인증서 가져오기

30일 무료 이용 가능한 인증서 발급 받은 후 진행 했다. 


IIS 최상단 노드에서 "서버 인증서" 선택


우측 상단 "가져오기" 선택해서 발급 받은 .pfx 인증서를 선택한다. 

인증서 저장소는 "웹 호스팅" 으로 지정한다. 개인으로 선택해도 되는데, 기술문서에서 웹 호스팅으로 선택 했다고 하니깐 그대로 따라해 본다. 



sni2.gunnm.xyz 인증서도 동일한 방식으로 가져온다. 


완료시 아래와 같이 확인 가능하다. 




# 3

바인딩에 https 프로토콜 추가


호스트 이름은 반드시 CN 과 동일하게 입력한다. 


ex) 

기존 등록 된 바인딩 : gunnm.xyz / www.gunnm.xyz


SNI 설정시 https 프로토콜 2개 추가 필요

https://gunnm.xyz

https://www.gunnm.xyz






# 4

https 페이지 호출 및 SSL 바인딩 목록 확인





cmd 실행 후, netsh http show sslcert 입력




SSL 바인딩 조회시, 아이피에 대한 443 할당이 아닌 (127.0.0.1:443) 각 호스트값에 443 포트가 할당 된 것을 확인 할 수 있다. 


다수의 웹사이트를 구동 중인 사용자에게 유용한 기능이라고 할 수 있다. 


업체에서 node.js 모듈 업데이트를 요청하였다. 


CMD 실행 후, npm install 을 입력했는데 잘 설치가 되는듯 싶더니 오류가 빡! 하고 나와버렸다. 심지어 컬러로 나온다. 




C:\Program Files\nodejs\node_modules\npm>npm install

npm WARN deprecated coffee-script@1.12.7: CoffeeScript on NPM has moved to "coffeescript" (no hyphen)

npm WARN deprecated ignore@2.2.19: several bugs fixed in v3.2.1

npm WARN deprecated istanbul-lib-hook@1.2.1: 1.2.0 should have been a major version bump

npm WARN deprecated hoek@2.16.3: The major version is no longer supported. Please update to 4.x or newer 

npm WARN notice [SECURITY] hoek has the following vulnerability: 1 moderate. Go here for more details: https://nodesecurity.io/advisories?search=hoek&version=2.16.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.

npm WARN notice [SECURITY] tunnel-agent has the following vulnerability: 1 moderate. Go here for more details: https://nodesecurity.io/advisories?search=tunnel-

agent&version=0.4.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.


> npm@5.6.0 prepare C:\Program Files\nodejs\node_modules\npm

> node bin/npm-cli.js --no-timing prune --prefix=. --no-global && rimraf test/*/

*/node_modules && make -j4 doc


npm notice created a lockfile as package-lock.json. You should commit this file.


up to date in 6.985s

'rimraf'은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다.

npm ERR! code ELIFECYCLE

npm ERR! errno 1

npm ERR! npm@5.6.0 prepare: `node bin/npm-cli.js --no-timing prune --prefix=. --no-global && rimraf test/*/*/node_modules && make -j4 doc`

npm ERR! Exit status 1

npm ERR!

npm ERR! Failed at the npm@5.6.0 prepare script.

npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

npm ERR!     C:\Users\Administrator\AppData\Roaming\npm-cache\_logs\2018-09-05T05_56_35_361Z-debug.log 


구글링을 또 해보자~

검색어 : 'rimraf'은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다.

결과 : https://github.com/gdi2290/angular-starter/issues/1997

CMD 에서 npm install rimraf -g 입력을 해본다. 


설치가 잘 된걸로 보인다. 

다시 npm install 입력한다. 


이상 없이 완료가 된 걸로 보인다. 

npm 관련해서 검색을 해보니깐, 뒤의 옵션에 -g 를 주면 어느 경로에서든 설치를 진행한다고 한다. 그러니깐 굳이 npm 설치 경로에서 실행 안해도 된다. 

자세한건 알아서 검색해보자. 


저번에는 MS-SQL 2012 Ent 이상의 버전에서 사용 가능한 AlwaysOn 기능을 통한 장애 조치를 테스트 했는데, 이번에는 그냥 클러스터링 기능을 이용한 장애 조치를 진행하려고 한다. 


# AD 가 구축되어 있음이 전제

DB1 : 211.115.90.52

DB2 : 211.115.90.53

Storage : 211.115.90.54

저장소 클러스터 IP : 211.115.90.55

DB 클러스터 IP : 211.115.90.56


# 1 

Storage 서버의 디스크 공간을 iSCSI 로 만들어서 클러스터링 저장 공간으로 사용하고자 한다. D 와 E 파티션을 iSCSI 로 사용한다. 


우선 Storage 서버에 접속하여 역할을 추가 한다. 


파일 및 저장소 서비스 - 파일 및 iSCSI 서비스 - iSCSI 대상 서버 체크 및 설치 진행



설치 완료가 되었으면, 서버 관리자를 열어서 파일 및 저장소 서비스를 선택한다.



iSCSI 항목으로 이동 후에, 새 가상 디스크 마법사를 선택한다. 



D 파티션을 선택 후 진행한다. 



가상 디스크 이름은 본인이 아무거나 쓰면 된다. 나는 CLUSTER_DISK 라고 했다. 



크기는 Full 로 사용할 거니깐 전체 공간 할당했다. 



다음에서는 새 iSCSI 대상을 선택 후 진행한다. 나같은 경우는 이전에 테스트했던 내역들이 남아서 저렇게 보이는 것 뿐이다. 



대상 이름이야뭐 중요하지 않으니깐 암거나 쓴다. 나는 DB-CLUSTER 로 했다. 



다음에는 가상 디스크에 액세스할 서버들을 추가해야 한다. 추가를 눌러서 DB1 과 DB2 를 넣는다.



다음은 그냥 Default 로 쭉쭉 간다. 



가상 디스크 생성 및 대상 서버를 확인 할 수 있다. 




E 파티션도 동일하게 iSCSI 디스크로 만들어준다. 





# 2

DB1 DB2 에서 가상 디스크에 연결되도록 설정을 한다. 

관리도구 확장해서 iSCSI 초기자 선택 후 아래처럼 진행한다. 



디스크 관리에서 가상 디스크 영역 추가 확인 할 수 있다. 



디스크를 활성화 해서 H 드라이브로 만든다. 




# 3

신규 클러스터를 새로 만든다. 


클러스터에 포함 될 서버들을 추가해야 하는데, 전 게시물에 동일한 내용이 있으니깐 스킵한다. 


클러스터 이름은 DB-CLUSTER 로 했다. 



DB1의 내 컴퓨터 및 디스크 관리 활성화하면 아래와 같이 확인 된다. 





DB2의 디스크 관리에서는 아래와 같이 확인 된다. 




# 4

SQL Server 장애 조치 클러스터를 새로 설치한다. 



SQL 기본 설치 하듯이 쭉쭉 진행하면 된다. 


인스턴스 구성시 기존에 사용하던게 있으니깐 새로 정해서 진행한다. 




DB 데이타 저장 영역은 클러스터링 된 G 파티션으로 설정하고 설치 진행하면 된다. (캡쳐를 안뜨고 진행해서 이미지는 없다.) 


정상적으로 SQLCLUSTER  설치가 완료 되었다. 









DB2 에서는 클러스터에 노드 추가로 진행한다. 


기본적으로 DB1에서 설정 된 값을 가져오기 때문에 특별히 할 건 없다. 계정의 패스워드 정도 입력하면 된다. 



설치가 완료되면 설정 완료를 위해서 재시작을 하라고 한다. 서버 리부팅 한 번 해주자. 



DB2 에서는 SQLCLUSTER 서비스 실행이 되지 않는다. DB1이 현재 구동 중이기 때문으로 추정 된다. 장애 조치시에 자동 시작이 되는건가 싶다. 


그런데, DB2 의 SSMS 실행 후, SQLCLUSTER 접속시 정상으로 진입 된다. 



DB 클러스터 IP 인 211.115.90.56 으로 접속이 되기 때문인것 같다. DB 1의 SQL 구성 관리자를 봐야겠다.




port 52255 로 DB 클러스터 구성 된게 확인 된다. 


이제 DB1 서버를 강제 종료하여, DB2 로 역할이 변경 되는지 확인해 본다. 






DB2 의 SQL 실행 및 DB 클러스터 IP 할당이 확인 되었다. 


DB1 서버 전원 ON 하면 어떻게 되는지 확인해 봤는데, 아무일도 일어나지 않는다. 역할 변경은 수동으로 해줘야 하는 것 같다. 


역할 변경 전에, DB2 의 SQLCLUSTER 에서 임시 DB 및 테이블을 생성해본다. 




이제 DB2 서버를 종료하고, DB1 에서 상태를 확인한다. 




DB2 에서 DB1 으로 다시 역할이 변경 되었다. 생성한 DB 및 테이블도 확인되었다. 


DB 클러스터링 테스트는 이상으로 종료한다.