node.js 모듈 설치를 위한 npm install 오류 발생 처리
업체에서 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 |
'윈도우 이야기 > Etc' 카테고리의 다른 글
| OS 업그레이드 테스트 2 (2012 R2 -> 2019) (2) | 2020.03.09 |
|---|---|
| Windows Server 2012 이상 버전의 가장 오래된 VSS 백업 복사본 삭제 (0) | 2019.08.23 |
| MS-SQL 2016 장애 조치 클러스터링 테스트 : MSCS 구성 (0) | 2018.08.28 |
| 액티브디렉토리 (Active Directory) 및 MSCS , AlwaysOn 구축 테스트 #2 (1) | 2018.08.23 |
| 액티브디렉토리 (Active Directory) 및 MSCS , AlwaysOn 구축 테스트 #1 (0) | 2018.08.23 |
MS-SQL 2016 장애 조치 클러스터링 테스트 : MSCS 구성
저번에는 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 클러스터링 테스트는 이상으로 종료한다.
'윈도우 이야기 > Etc' 카테고리의 다른 글
| Windows Server 2012 이상 버전의 가장 오래된 VSS 백업 복사본 삭제 (0) | 2019.08.23 |
|---|---|
| node.js 모듈 설치를 위한 npm install 오류 발생 처리 (1) | 2018.09.05 |
| 액티브디렉토리 (Active Directory) 및 MSCS , AlwaysOn 구축 테스트 #2 (1) | 2018.08.23 |
| 액티브디렉토리 (Active Directory) 및 MSCS , AlwaysOn 구축 테스트 #1 (0) | 2018.08.23 |
| OS 업그레이드 테스트 (Windows 2008 R2 -> 2012 R2 -> 2016) (12) | 2018.06.27 |
액티브디렉토리 (Active Directory) 및 MSCS , AlwaysOn 구축 테스트 #2
액티브디렉토리 (Active Directory) 및 MSCS 구축 테스트 #1 에 이어서 작성....
모든 사용자 접속 계정은 AD 관리자 계정으로 진행한다.
가상화 서버 4대
AD DC : 211.115.90.51
DB1 : 211.115.90.52
DB2 : 211.115.90.53
Storage : 211.115.90.54
방화벽 정책 추가 : In/Outbound : TCP 135, 445, 3343 / UDP 3343
# 1
가상화 서버 4대 중 스토리지 서버의 디스크 공간을 DB 의 공유 폴더로 사용을 하려고 한다.
데이타 파티션 D 드라이브에 아무 폴더나 생성 하고 공유 설정을 진행한다.
공유 경로 : \\STORAGE\AO_Storage
처음 의도는 iSCSI 를 구축해서 클러스터링 디스크를 만들려고 했는데, 테스트해보니깐 공유 폴더랑 차이가 없어서 그냥 진행한다.
공유 폴더를 생성했으니, DB 서버에서 해당 폴더로 네트워크 연결을 시도해 본다. 이따가 AlwaysOn 구축시 필요하므로 꼭 연결 체크 해야한다.
# 2
DB1 / DB2 서버에 장애 조치(Failover) 클러스터링을 설치를 한다.
DB1 / DB2 동일 작업
역할 및 기능 추가를 통해서 설치를 진행한다.
DB1 단독 작업
DB1 의 관리 도구 열어서 장애 조치(Failover) 클러스터 관리자 실행한다.
설정 된게 없기 때문에 아무것도 없다.
클러스터 만들기를 선택 후 진행한다.
서버 이름 입력에서 "찾아보기" 선택해서 DB1 과 DB2 를 넣어준다.
클러스트 관리 이름은 AO 로 한다. AlwaysOn 테스트 이기 때문이다. 뭐 본인이 편한거 아무거나 해도 된다. 딱히 큰 의미는 없다.
아래에 추가해야 하는 클러스터 관리자 아이피는 AD 그룹과 동일 대역의 미사용 아이피를 입력한다.
네트워크 : 211.115.90.0/26
주소 : 211.115.90.55
Default 로 쭉쭉 간다. 완료 되면 아래와 같이 확인 가능하다.
이제 장애 조치 설정은 대충 마무리 되었다.
# 3
DB1 / DB2 에 MS-SQL 2016 및 SSMS 설치를 진행한다.
그냥 본인이 원하는 방식대로 설치를 진행하면 된다.
설치가 정상적으로 완료가 되었으면, 몇 가지 변경 작업을 진행해보자.
DB1 및 DB2 동일 작업
서비스 실행
SQL Server (MSSQLSERVER) 및 SQL Server 에이전트 (MSSQLSERVER) 의 로그온 계정을 AD 관리자 계정으로 변경한다.
위 방식은 내가 편할려고 하는 거니깐 이 방식이 맞다고 할 수는 없다. 알아서 하면 되지 않을까 싶다.
SQL Server 2016 구성 관리자 실행 후 AlwaysOn 고가용성 사용을 체크한다.
각 DB 서버에서 SSMS 실행 후,
보안 - 로그인 - AD 계정 선택 - 속성
서버 역할 : sysadmin 추가
사용자 매핑 : master 선택 / db_owner 선택
여기까지가 DB 의 기본 설정 부분이다.
# 4
DB 및 AlwaysOn 고가용성 그룹 생성을 진행한다.
DB1 에서 임의의 데이타 베이스를 생성한다.
나는 AO1 로 생성했다.
Always On 고가용성 에서 가용성 그룹을 신규 생성한다. 마법사로 진행하면 편하다.
다음 단계로 넘어가면 AO1 DB 에 백업이 되어 있지 않다고 진행이 안 된다. 한 번 전체 백업 실행 해주고 다음으로 넘어간다.
복제본 지정 단계가 나오는데, 복제본 추가를 눌러서 DB2 를 끌어온다.
모든 서버의 접속 계정 및 SQL 서비스 실행 계정이 AD 관리자 계정 이므로, Windows 인증으로 해도 된다. 본인이 다르게 설정 했으면 알아서 하면 된다.
DB2 와 연결이 정상적으로 되면, 보조 영역에 추가 된다. 나머지 설정들은 그냥 스킵해도 된다.
다음 단계에서 데이터 동기화를 위한 백업 경로 지정이 있는데, 여기에 아까 생성했던 스토리지의 공유 폴더 경로를 등록한다.
그런데 오류가 발생해서 그룹 생성이 실패한다.
오류 문구를 확인해 보니, 기존 클러스터 구성이 삭제 되었기 때문에 SQL 구성 관리자에서 AlwaysOn 기능을 해제 했다가 다시 적용을 해야 한단다.
게시글 작성을 위해 모든 설정 초기화 하고 다시 진행 했더니 이런 오류가 생겼다.
오류 발생 처리에 관해서도 확인이 됐으니 다행으로 생각한다.
가용성 그룹 생성 완료 되면, DB1 에서는 아래와 같이 확인 된다.
DB2 에서는 아래와 같이 데이타베이스 접근 불가 확인된다. 장애 대비를 위한 대기 상태 이므로 기능이 전부 제한된다.
# 5
장애 조치 테스트를 진행해야 하므로, DB1 서버를 종료한다.
장애 조치 클러스터 소유자 노드가 DB-2 로 변경 되었다.
DB 가용성 그룹의 Master 와 Slave 역할이 변경 되었다.
다시 DB1 서버를 켜고, 역할 복원을 진행한다.
장애 조치로 역할이 변경 되면, 서비스가 복구 되어도 자동으로 원복이 되지 않는다.
수동으로 역할 변경 해줘야 한다. 이 부분은 약간 좀 그런듯 하다.
DB1 또는 DB2 에서 AOG그룹 선택 후 장애 조치 진행하면 된다.
그 전에, 장애조치를 통한 데이타 동기화를 확인해야 하므로 활성화 된 DB2 에서 임시 테이블을 생성한다.
create table gunnm_test (
Number varchar(50) null,
ID varchar(50) null,
PW varchar(50) null,
NAME varchar(50) null,
)
테이블 생성도 했으니깐, 장애 조치를 강제로 진행한다.
장애 조치 수동 진행 후, 클러스터 소유자 노드가 다시 DB-1 로 변경 되었다.
DB Master 와 Slave 역할도 변경 되었다. DB2 에서 생성한 임시 테이블도 조회가 된다.
SQL 미러링은 모니터링 서버를 구축해야지만 자동 장애 조치가 진행되는데 반해, AD 를 통한 클러스터링은 자기들이 알아서 진행하니 편리하긴 한다.
다만, 다시 원상태로 복구는 수동으로 진행해야 하므로, 반드시 서비스 장애 모니터링을 해야 한다.
'윈도우 이야기 > Etc' 카테고리의 다른 글
| node.js 모듈 설치를 위한 npm install 오류 발생 처리 (1) | 2018.09.05 |
|---|---|
| MS-SQL 2016 장애 조치 클러스터링 테스트 : MSCS 구성 (0) | 2018.08.28 |
| 액티브디렉토리 (Active Directory) 및 MSCS , AlwaysOn 구축 테스트 #1 (0) | 2018.08.23 |
| OS 업그레이드 테스트 (Windows 2008 R2 -> 2012 R2 -> 2016) (12) | 2018.06.27 |
| 계정 생성 스크립트 (0) | 2018.06.14 |
