스마일서브 CDN 사업부에서 근무하고 있으며 동영상호스팅, 이미지호스팅에 대한 서비스 설명 및 기술 적인 이슈들을 기재하고 있습니다.
매번 사용자 계정 컨트롤 메시지가 나오면 작업하기 상당히 번거스러움으로 아래와 같이 작업해주면 다시 묻지 않는다
제어판 - 사용자계정 - 사용자 계정 컨트롤 사용 / 사용안함 - 사용자 계정 컨트롤을 사용하여 컴퓨터를 보다 안전하게 보호 체크해제 - 리부팅
윈도우 서버를 사용할때 2개 세션 초과하여 접속할려고 할때 (별다른 설정이 없다면)
세션초과로 원격접속을 할수없다고 메세지가 나옵니다.
이때 직접 서버앞에서 콘솔을 붙여서 접속하지 않더라도 원격으로 로컬 화면을 접속할수있는 간단한 팁입니다.
구버젼 터미널 프로그램 사용시 시작 -> 실행 을 여시고. mstsc /console /v: ip 이렇게 적어주시면 되시고요.
신버젼 터미널 프로그램 사용시[sp3 이상 비스타 버젼들] mstsc /admin /v: ip 이렇게 사용하시면 바로 콘솔화면을 붙일수 있습니다.
SQL Server 2005 Database Mirroring
테크데이타
SQL Server 2005 Database Mirroring 개요
데이터베이스 미러링은 데이터베이스의 가용성을 높여 주는 주요 소프트웨어 솔루션입니다. 미러링은 데이터베이스 단위로 구현되며 전체 복구 모델을 사용하는 데이터베이스에서만 작동합니다.
단순 복구 모델 및 대량 로그 복구 모델에서는 데이터베이스 미러링이 지원되지 않습니다.데이터베이스 미러링은 상시 대기 서버를 유지함으로써 작동합니다.
일반적인 미러링 세션 중 프로덕션 서버에 문제가 발생하면 클라이언트 응용 프로그램에서 대기 서버에 다시 연결하여 빠르게 복구할 수 있습니다.
참고로, master, msdb, tempdb 또는 model 데이터베이스는 미러링할 수 없습니다. 데이터베이스 미러링에는 일반적으로 서로 다른 컴퓨터에 상주하는 2개의 단일 데이터베이스 복사본이 사용됩니다.
클라이언트는 항상 하나의 데이터베이스 복사본만 사용할 수 있습니다. 이 복사본을 주 데이터베이스라고 합니다.
클라이언트가 주 데이터베이스에 수행한 업데이트는 미러 데이터베이스라고 하는 다른 데이터베이스 복사본에 미러링됩니다.
미러링에는 주 데이터베이스에 대해 수행된 모든 삽입, 업데이트 또는 삭제 작업의 트랜잭션 로그를 미러 데이터베이스에 적용하는 작업이 포함됩니다.
주 데이터베이스와 미러 데이터베이스는 별개의 서버 인스턴스(즉, Microsoft SQL Server 데이터베이스 엔진 의 인스턴스)에 상주해야 합니다.
두 서버 인스턴스는 데이터베이스 미러링 세션에서 파트너로서 통신하고 협력합니다. 두 파트너는 세션에서 서로 보완되는 주 역할과 미러 역할을 수행합니다.
언제든지 한 파트너는 주 역할을 수행하고 다른 파트너는 미러 역할을 수행합니다.
각 파트너는 현재 역할을 소유한다고 표현합니다. 주 역할을 소유하는 파트너를 주 서버라고 하며 주 서버의 데이터베이스 복사본이 현재의 주 데이터베이스입니다.
미러 역할을 소유하는 파트너를 미러 서버라고 하며 미러 서버의 데이터베이스 복사본이 현재의 미러 데이터베이스입니다
데이터베이스 미러링은 SQL Server Standard Edition 및 Enterprise Edition에서 완벽하게 지원됩니다.
SQL Server Workgroup Edition 또는 Express Edition에서 실행되는 서버 인스턴스는 미러링 모니터 서버 역할만 지원합니다.
[참고] SQL Server 2005 서비스팩1 부터 정식으로 사용 가능하며, 서비스팩1이 설치되지 않은 SQL서버는 추적플래그 1400을 활성화하여 서비스를 시작하면 미러링 기능을
이용할 수 있습니다.
데이터베이스 미러링은 운영 형태에 따라서 High Availablity, High Protection, High Performance 3가지로 분류 할 수 있습니다.
1. High Availablity 형태 : 자동으로 Failover처리, Principal, Mirror, Witness 인스턴스가 각각 필요.
2. High Protection 형태 : 수동으로 Failover처리, Principal, Mirror 인스턴스가 각각 필요.
3. High Performance 형태 : 트랜잭션이 principal서버와 Mirror서버에 반영되었는지 확인하지 않음, 따라서 성능의 이점은 있음.
수동으로 Failover처리, Principal, Mirror 인스턴스가 각각 필요.
SQL Server 2005 Database Mirroring 구현 따라하기
[사전준비사항]
1. 3개의 SQL서버 2005 인스턴스 (테스트 이므로 하나의 서버에 3개의 인스턴스로 진행합니다.).
- Principal 서버 : ADFSACCOUNT
- Mirror 서버 : ADFSACCOUNT\SQL2005_2ND
- Witness 서버 : ADFSACCOUNT\SQL2005_3RD
2. 미러링을 구현할 Database 명
- BELLVIRUS
[따라하기]
1. Principal 서버에서 미러링을 할 데이터베이스를 백업한다. 데이터 베이스의 복구 모델은 Full 이어야 합니다.
BACKUP DATABASE BELLVIRUS TO DISK = 'D:\BACKUP\BELLVIRUS.BAK' WITH INIT
2. 백업한 파일을 이용하여 Mirror서버에서 NORECOVERY 옵션으로 복원한다
RESTORE DATABASE BELLVIRUS FROM DISK ='D:\BACKUP\BELLVIRUS.BAK'
WITH MOVE 'BELLVIRUS' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.4\MSSQL\DATA\BELLVIRUS.mdf',
MOVE 'BELLVIRUS_log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL.4\MSSQL\DATA\BELLVIRUS_log.LDF', NORECOVERY
3. 아래 그림 처럼 MIRROR서버의 BELLVIRUS 데이터베이스가 (복원중…)으로 표시될 것입니다.
이제 미러링 설정을 위해서 주 서버의 BELLVIRUS 데이터베이스의 속성창을 띄우십시요.
4. 데이터베이스 속성 창의 미러링 페이지를 선택하고, 오른쪽 상단의 ‘보안구성’ 버튼을 누릅니다.
5. 데이터베이스 미러링 보안 구성 마법사가 뜹니다.
6. 미러링 모니터 서버를 포함 여부를 물어옵니다.
모니터서버는 위에서 살펴본 WITNESS서버를 의미합니다. 여기서는 고가용성을 위한 테스트 이므로 포함시키도록합니다.
7. 마찬가지로 모니터 서버 인스턴스에도 보안구성을 저장한다고 선택합니다.
8. 주 서버 인스턴스에 대한 포트 및 끝점 이름을 설정합니다.
9. 같은 방식으로 미러서버 인스턴스와 Witness서버 인스턴스 설정도 합니다.
아래 그림처럼 연결이 되지 않은 상태에서는 주의표시가 뜹니다. 연결버튼을 눌러 연결을 맺으면 됩니다.
10. 각 서버의 서비스 계정을 지정하는 화면입니다.
지시내용에 따라 입력을 하십시요. 이번 테스트는 단일 머신에서 진행하는 관계로 입력란을 비워둡니다.
각 서버가 독립된 머신에서 구성을 할 경우에는 서버 상호간에 연결 권한을 피연결서버측에 허용해주어야 합니다.
이 단계에서 각 서버의 계정을 지정하면, 피연결서버측에서 자동으로 연결권한을 부여하게 됩니다.
11. 설정 요약 정보를 검토한 후 마침을 누릅니다.
12. 미러링 보안 구성이 성공적으로 완료 됩니다. 13. 완료후 데이터베이스 미러링을 지금 시작하겠냐고 물어옵니다. 14. 미러링이 시작된 미러링 페이지의 모습입니다. 15. 미러링이 구성된 후의 SQL서버 트리 모습입니다. 변경된 아이콘을 봐두시기 바랍니다. 16. 그럼 이제 몇 개의 트랜잭션을 발생시키고, FAILOVER를 시켜서 정상적으로 미러링이 되고 있는지 확인 해보겠습니다. 17. 주서버에서 FAILOVER를 발생시킨후 미러서버쪽에서 데이터를 살펴보겠습니다. 18. 그럼 바뀐 주서버의 BELLVIRUS 데이터베이스에서 TEST2테이블의 내용을 조회해 보겠습니다. 19. 이상으로 간단하게 SQL SERVER 2005의 데이터베이스 미러링을 구현해보았습니다. 마치며.. SQL2005의 데이터베이스 미러링의 기능이 추가되면서, 가용성 높이기 위한 구현 방법이 한가지 더 늘어났습니다. 데이터베이스 단위의 standby개념이라면, 미러링이 가장 좋은 솔루션이 될 것 같습니다. 테스트 해 본 바로는 주 데이터베이스의 장애시점에 3초 이내에 미러 서버에서 서비스가 가능함을 확인하였습니다. SQL서버가 제공하는 여러 가지 가용성 솔루션 (클러스터링, 미러링, 복제, 로그전달)의 각각의 장단점이 있으니, 이를 잘 인지하여 주어진 상황에 맞는 솔루션을 선택하시기 바랍니다.
시작하셔두 되구, 데이터 베이스 속성의 미러링 페이지에서 나중에 시작하셔도 무방합니다.
운영모드의 주석을 잘 읽어보시기 바랍니다.
주서버의 BELLVIRUS 데이터베이스에서 아래의 쿼리를 실행합니다.
주서버와 미러서버에서 각각 프로필러를 띄워서 입력되는 트랜잭션을 살펴보았으나, 미러서버쪽에서는 아무런 내용도 캡처되지 않았습니다.
주서버의 BELLVIRUS 데이터베이스의 속성창의 미러링 페이지에서 ‘장애조치’버튼을 클릭합니다.
장애조치를 하게되면 주서버와 미러서버가 서로 전환되고, 현재 주서버의 BELLVIRUS데이터베이스는 연결 할 수 없다는
경고성 문구가 뜹니다. 숙지하신후 예를 눌러 장애조치를 시킵니다.
장애조치는 순식간에 끝나버립니다. MANAGEMENT STUDIO의 SQLSERVER트리를 새로고침해서 확인하면 아래그림처럼
주서버와 미러서버의 역할이 서로 바뀐 것을 확인 할 수 있습니다.
결과 값이 정확히 일치 하는 것을 확인 할 수 있습니다.
[출처] SQL Server 2005 Database Mirroring|작성자 함만맨
아무튼 제작사 측에서 어마어마한 MSSQL 라이센스 비용을 절감할 수 있는 절호의 기회를 제공해 주었으니 사용자 입장에서는 잘 써주는 게 인지상정 아니겠는가. 물론, 발표한지 꽤나 시간이 흐른 제품이기 때문에 이미 여러모로 잘 사용하고 계신 분들이 많을 거라 추정된다.
본 글에서는 MSSQL 2005 Express 에디션의 제약 조건에 대해서 살펴볼까 한다.
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
‘전체텍스트검색’의 용도를 간단히 예를 들어 설명해 보자면 다음과 같다.
‘A’라는 게시판에 본문 검색 기능이 탑재되어 있다. 그리고 사용자가 ‘윈도우’라는 단어로 본문 검색을 시도했다면 아래와 같거나 또는 유사한 쿼리가 SQL 서버에 결과값을 요청하게 될 것이다.
SELECT * FROM aboard WHERE contents LIKE ‘%윈도우%’ ORDER BY idx DESC
DB 양이 얼마 되지 않는다면 처리하는데 큰 문제가 없겠지만, 글 수가 몇 십, 백만 건 또는 그 이상이라면 분명 SQL 서버는 큰 부하를 겪게 될 것이다. ‘aboard’ 테이블의 ‘contents’ 컬럼에서 ‘윈도우’라는 단어로 전체 검색을 해야 하기 때문입니다.
‘전체텍스트검색’은 바로 이런 부분들을 효율적으로 관리하기 위해 마련된 기능이라 할 수 있다. 쉽게 정리하자면 특정 테이블의 특정 컬럼에서 미리 단어들를 추출 및 정리해 놓았다가 위의 예 처럼 본문 검색 기능 등에 적용하여 유용하게 사용하는 것이다.
물론 MS-SQL 엔진 자체 내에도 인덱스라는 기능이 있다. 하지만, ‘전체텍스트검색’과는 성질이 다소 다르다고 할 수 있다. ‘전체텍스트검색’은 엄연히 MS-SQL 엔진 범주에 포함된 부분이지만, ‘전체텍스트검색’의 데이터라 할 수 있는 카탈로그와 자체 인덱스의 관리는 MS-SQL 엔진이 아닌 윈도우즈 파일시스템을 사용하고 있기 때문이다. 그리고 SQL 인덱스와는 달리 ‘전체텍스트검색’의 인덱스는 수동으로 갱신해 주어야 한다. 이때 발생하는 엄청난 I/O 부하는 여전히 해결해야 할 난제로 알고 있다.
아무튼 기본적으로 MSSQL 2005 Express 에디션은 '전체텍스트검색'을 지원하지 않는다.
하지만!!!
'Microsoft SQL Server 2005 Express Edition with Advanced Services SP2' 이녀석을 설치하면 '전체텍스트검색' 기능을 사용할 수 있다. '전체텍스트검색'이 일반적으로 자주 사용되는 기능은 아니지만 이왕이면 새옹지마라고…
다운로드 경로는 아래 링크 주소를 참고하시기 바란다.
MSSQL 2005 Express 에디션은 다중 프로세서를 지원하지 않는다. 물론, 다중 프로세서가 장착된 서버에서 설치 또는 실행 자체가 되지 않는 것은 아니다.
유의할 사항은 순수 DATA 용량만을 가지고 계산하는 것이기 때문에 4GB 용량 제한에는 트랜젝션로그 용량은 포함되지 않는다. 아울러 데이터베이스 개수에는 별도의 제한 사항이 없다.
SSIS란, SQL Server Integration Services의 약자로써 쉽게 말하자면 DTS의 강화판이라 할 수 있다. MSSQL 2000에서도 타 기종 간의 데이타 이전이나 외부 SQL 서버에 보존된 데이타 가져오기 또는 반대로 데이터 내보내기 기능등은 어느 정도 수준까지 지원했으나 SSIS에서는 이 기능을 좀 더 강화하여 따로 독립된 서비스로 분류하고, 플로우(Flow) 자체를 엔진화 했다.
이런 좋은 기능을 MSSQL 2005 Express 에디션에서는 공식적으로 지원하지 않는다는 것이 매우 안타까울 다름이다. 하지만, 그보다 서버 이전이나 차후에 발생할 수 있는 상황들을 고려해 봤을 때 DTS 기능을 사용할 수 없다는 것은 참으로 난감한 일이 아닐 수 없다.
일단, 'Microsoft SQL Server 2005 Express Edition Toolkit SP2'를 설치하면 DTS 기능을 사용할 수 있다. 다운로드 경로는 아래 링크 주소를 참고하시기 바란다.
설치가 완료되었다면 '설치폴더\90\DTS\Binn\DTSWizard.exe'파일을 수동으로 실행시켜 필요시마다 DTS 기능을 사용할 수 있다.
| 기본값으로 2008은 Windows가 로딩될 때의 기본 기능 후에는 multi-processor core를 검출하고 스위칭하지만, 실제적인 부팅 시에는 단지 단일 코어만을 사용합니다. (dual-core, quad-core) processor를 장착한 컴퓨터에서 64-bit 버전의 Server 2008을 운용 중이라면, 단순한 설정으로 컴퓨터의 부팅 속도를 조금이나마 향상시킬 수 있습니다. [시작]의 [실행] 입력창에 "msconfig"를 타자 후 엔터키를 누릅니다. [고급 부팅 옵션] 창에서 [프로세서 수] 항목의 드롭다운 버튼을 눌러 사용자 컴퓨터에서 선택 가능한 최대 숫자를 선택합니다. [최대 메모리]는 기본값으로 그대로 두십시오. 오류인지 버그인지 설정을 변경하면 OS에서 메모리를 제대로 인식을 못합니다. 프로세서수만 수정하고, 창을 닫은 후 재부팅하여 결과를 확인 해 보십시오. 이 설정의 변경이 무의미 한것이라고 간주되기도 하지만, 많은 경우에 실제적인 도움이되므로 적용은 사용자 각자의 몫입니다 |
System Center Data Protection Manager 2007 is a member of the Microsoft System Center family of management products, which are designed to help IT Professionals manage their Windows Server infrastructure. SCDPM 2007 sets a new standard for Windows backup and recovery—delivering continuous data protection for Microsoft application and file servers to a seamlessly integrated secondary disk and tape solution on the SCDPM server. DPM enables rapid and reliable recovery through advanced technology for enterprises of all sizes.
This article will demonstrate how to install System Center Data Protection Manager (SCDPM) 2007 on a Windows Server 2008.
Although Microsoft has a prescribed way to install SCDPM (http://technet.microsoft.com/en-us/library/bb808735.aspx) I’ve found that it doesn’t always go according to plan; leaving me with an installation which doesn’t work as designed or a completely failed installation.
Follow these steps to install all the required Windows Server 2008 features:
Before installing DPM on any of the servers, it is very important to ensure that the Single Instance Store (SIS) is installed. SIS is a core requirement for SCDPM. The following procedure outlines the steps required to install SIS:
start /wait ocsetup.exe SIS-Limited /quiet /norestart
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SIS
The following steps show how to install SCDPM 2007 on the server:
SCDPM is now installed on the server.
Service Pack 1 (SP1) includes a number of fixes which among other, are required for advanced Hyper-V support. Follow these instructions in order to install the service pack:
This article has demonstrated a field tested procedure for installing System Center Data Protection Manger 2007 on Windows Server 2008 and highlighted a number of steps which are sure to save you a lot of problems during the installation. With this knowledge, you are well informed on how to install SCDPM in your enterprise.
Installing DPM
http://www.microsoft.com/downloads/details.aspx?FamilyId=8AE5EDAC-4DE8-44E0-A6F9-8AFBB3E23585&displaylang=en
System Center Data Protection Manger 2007 – Overview
http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/overview.aspx
보호 그룹은 동일한 보호 구성을 공유하는 데이터 원본의 모음입니다. 보호 그룹 내의 데이터 원본을 보호 그룹 구성원이라고 합니다.
첫 번째 보호 그룹을 만들기 전에 저장소 풀에 디스크를 추가하고 보호할 컴퓨터에 에이전트를 설치해야 합니다. 이 작업을 완료하는 방법에 대한 자세한 내용은 DPM 2007 Deployment Guide를 참조하십시오.
보호 그룹을 만들려면 새 보호 그룹 만들기 마법사를 사용합니다.
DPM을 사용하여 보호할 수 있는 보호 그룹 구성원은 다음과 같습니다.
DPM 관리자 콘솔의 탐색 모음에서 보호를 클릭합니다.
작업 창에서 보호 그룹 만들기를 클릭합니다. 새 보호 그룹 만들기 마법사가 나타납니다.
시작 페이지를 검토하고 다음을 클릭합니다.
| 참고 |
|---|
| 나중에 보호 그룹을 만들 때 마법사의 시작 페이지를 표시하지 않으려면 이 시작 페이지를 다시 표시 안 함을 선택하십시오. |
새 보호 그룹의 가상 인스턴스를 만들려면 다음 구문을 사용합니다.
New-ProtectionGroup [-DPMServerName] <String> [[-Name] <String> ] [-Verbose] [-Debug] [-ErrorAction <ActionPreference> ] [-ErrorVariable <String> ] [-OutVariable <String> ] [-OutBuffer <Int32> ]
새 보호 그룹에 데이터 원본을 추가합니다.
필요한 경우 제외할 항목과 작업 시작 시간을 설정합니다.
보호 유형을 설정합니다.
복제본 만들기 방법을 설정합니다.
정책 목표를 설정합니다.
새 보호 그룹을 저장하려면 다음 구문을 사용합니다.
Set-ProtectionGroup [-ProtectionGroup] <ProtectionGroup> [-Async] [-TranslateDSList <Datasource[]> ] [-Verbose] [-Debug] [-ErrorAction <ActionPreference> ] [-ErrorVariable <String> ] [-OutVariable <String> ] [-OutBuffer <Int32> ]
자세한 내용을 보려면 DPM 관리 셸에서 "Get-Help New-ProtectionGroup -detailed"를 입력하십시오.
기술 정보를 보려면 DPM 관리 셸에서 "Get-Help New-ProtectionGroup -full"을 입력하십시오.
보호 그룹은 공통된 보호 구성이 지정된 데이터 원본의 모음(예: 볼륨, 공유 또는 Exchange Server 사서함)입니다. 보호 그룹 내의 데이터 원본을 보호 그룹 구성원 또는 간단히 구성원이라고 합니다. 보호 그룹 구성에서는 실시간 압축 및 일별 일관성 확인과 같이 사용할 성능 옵션을 지정합니다. 보호 정책에서는 복제본을 보호된 컴퓨터의 라이브 데이터와 동기화할 빈도 및 복제본의 복구 지점을 만들 시기를 지정합니다.
데이터를 보호 그룹으로 구성할 방법을 결정할 때는 조직의 업무 요구 사항, 네트워크 성능, 데이터 특성 등을 고려해야 합니다. 예를 들어 데이터 변경 빈도, 데이터 크기 증가 속도 및 손실 데이터의 최근 복사본을 복구하는 기능의 중요도를 고려해야 합니다. 또한 테이프에 데이터를 백업해야 할 빈도, 암호화 또는 압축이 필요한 데이터 및 사용할 수 있어야 하는 백업 복사본의 수도 고려해야 합니다. 대부분의 경우 유사한 특성을 가진 데이터 그룹을 만들 수 있습니다.
다음 표에서는 Microsoft System Center Data Protection Manager(DPM)에서 보호하는 데이터 원본과 DPM을 사용하여 복구할 수 있는 데이터 수준을 보여 줍니다.
| 제품 | 보호 가능한 데이터 | 복구 가능한 데이터 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
보호 그룹에 추가된 데이터 원본은 그룹의 구성원이 됩니다. 데이터 보호를 시작하기 전에 하나 이상의 보호 그룹을 만들어야 합니다. 보호 그룹에 대한 자세한 내용은
문제 해결을 시작하기 전에 작업에 방해가 될 수 있는 다음과 같은 문제가 없는지 확인해 보십시오. 에이전트 문제 해결에 대한 자세한 내용은 DPM 2007 Deployment Guide의
데이터 보호를 시작하려면 먼저 보호할 데이터가 들어 있는 각 컴퓨터에 보호 에이전트를 설치해야 합니다. 컴퓨터에 보호 에이전트가 설치되어 있으면 해당 컴퓨터는 관리 작업 영역에서 보호된 컴퓨터로 나타납니다. 그러나 컴퓨터의 데이터 원본은 보호 그룹에 추가될 때까지 보호되지 않습니다.
DPM 서버에서 DPM 관리자 콘솔의 탐색 모음에 있는 관리를 클릭하고 에이전트 탭을 클릭합니다.
작업 창에서 설치를 클릭합니다. 보호 에이전트 설치 마법사가 나타나고 사용 가능한 컴퓨터 목록이 표시됩니다.
컴퓨터 선택 페이지에서 보호할 컴퓨터를 선택하고 추가를 클릭합니다. 해당 컴퓨터가 선택한 컴퓨터 창에 표시됩니다.
다음을 클릭합니다.
자격 증명 입력 페이지에서 자격 증명을 입력하고 다음을 클릭합니다.
다시 시작 방법 선택 페이지에서 보호 에이전트를 설치한 후 컴퓨터를 다시 시작하는 데 사용할 방법을 선택합니다.
| 참고 |
|---|
| 워크스테이션의 경우 보호 에이전트를 설치할 때 다시 시작 과정이 필요하지 않습니다. 서버는 다시 시작해야 데이터 보호를 시작할 수 있습니다. 보호 에이전트가 제대로 설치되도록 하려면 서버를 다시 시작해야 합니다. 서버를 수동으로 다시 시작하도록 선택한 경우에는 보호 에이전트를 설치한 후 작업 창의 정보 새로 고침을 클릭하여 에이전트 정보를 새로 고쳐야 합니다. |
6단계에서 선택한 컴퓨터가 클러스터된 서버인 경우 클러스터된 서버를 다시 시작하는 데 사용할 방법을 선택할 수 있는 다시 시작 방법 선택 페이지가 한 번 더 나타납니다.
| 중요 |
|---|
| 클러스터된 데이터를 제대로 보호하려면 서버 클러스터의 모든 노드에 보호 에이전트를 설치해야 합니다. 서버를 다시 시작해야 데이터 보호를 시작할 수 있습니다. 보호 에이전트가 제대로 설치되도록 하려면 서버를 다시 시작해야 합니다. 다시 시작한 후 서비스를 시작하는 데는 시간이 걸리므로 DPM에서 서버에 연결하는 데 몇 분 정도의 시간이 걸릴 수 있습니다. |
| 참고 |
|---|
| Microsoft Cluster Server(MSCS)에 속하는 서버는 다시 시작되지 않습니다. MSCS 클러스터의 서버는 수동으로 다시 시작해야 합니다. |
요약 페이지의 작업 탭에서 <computer name>에 보호 에이전트 설치 작업이 표시되어 있는지 확인하고 설치를 클릭하여 설치를 계속 진행합니다. 설치 성공 여부를 나타내는 결과가 작업 탭에 나타납니다.
설치 페이지에서 닫기를 클릭합니다.
Data Protection Manager 2007에서는 다음을 비롯한 다양한 백업 시나리오가 지원됩니다.
DPM 데이터 보호 기능에는 디스크 기반 저장소나 테이프 기반 저장소 또는 둘 모두를 사용할 수 있습니다.
D2D(Disk-to-Disk)라고 하는 디스크 기반 저장 방법은 한 컴퓨터의 데이터를 다른 컴퓨터의 하드 디스크에 저장하는 백업 유형입니다. 이와 달리 D2T(Disk-to-Tape)라고 하는 보다 일반적인 방법은 한 컴퓨터의 데이터를 테이프와 같은 저장소 미디어에 백업하는 것입니다. 보다 효과적인 보호를 위해 두 방법을 D2D2T(Disk-to-Disk-to-Tape) 구성으로 함께 사용할 수 있습니다. 이렇게 하면 빠른 복구가 장점인 단기 디스크 기반 저장소를 사용하면서도 중요한 데이터는 장기 테이프 기반 저장소를 사용하여 보관용으로 저장할 수 있습니다.
Data Protection Manager(DPM)를 사용하면 네트워크에서 응용 프로그램 서버, 파일 서버 및 워크스테이션의 데이터 보호 및 복구 과정을 관리할 수 있습니다. 이 항목에서는 DPM 환경에서 데이터를 성공적으로 보호 및 복구하기 위해 수행해야 하는 단계를 간략히 설명합니다.
DPM 보호 과정에는 보호된 데이터의 전체 복제본을 만들고 유지 관리하는 작업과 동기화된 복제본의 복구 지점을 정기적으로 만드는 작업이 포함됩니다. 복제본은 보호된 데이터의 전체 백업으로 사용됩니다. 복구 지점을 사용하면 이전 버전의 보호된 데이터를 복구할 수 있습니다. 다음 그림에서는 보호 과정을 보여 줍니다.
DPM에서 보호하는 대상이 파일 서버인지, 워크스테이션인지, 응용 프로그램 서버인지에 상관없이 보존 범위는 항상 64일로 제한됩니다. 각 데이터 원본 유형의 최대 복구 지점 수는 다음 표에 나와 있습니다.
| 데이터 원본 유형 | 최대 복구 지점 수 |
|---|---|
|
파일 |
64개 |
|
응용 프로그램(예: Exchange Server 또는 SQL Server) |
최대 64일 동안 매일 96개씩 |
|
Windows SharePoint Services |
최대 64일 동안 512개 |
|
Virtual Server |
최대 64일 동안 512개 |
DPM 복구 과정에는 DPM 서버에 저장된 복구 지점에서 이전 버전의 데이터 원본을 선택한 다음 선택한 데이터의 복사본을 보호된 서버의 원본 지점에 복원하는 작업이 포함됩니다. 다음 그림에서는 복구 과정을 보여 줍니다.
다음은 DPM을 사용하여 데이터를 보호하는 방법에 대한 예제입니다.
DPM에서는 데이터 보호 요구 사항을 충족하는 동기화 및 복구 지점 일정을 선택하여 두 볼륨 모두의 데이터를 보호할 수 있습니다.
보호 그룹 InvOrders를 만들고 공유 Z를 이 보호 그룹에 구성원으로 추가합니다. 자세한 내용은 보호 그룹을 만드는 방법을 참조하십시오.
동기화 빈도를 선택하고 하루 동안 8개의 복구 지점을 만들도록 예약합니다.
DPM에서 공유 Z의 복제본이 만들어지고 최대 64개의 복구 지점이 생성될 때까지 매일 8개씩의 복구 지점이 만들어집니다. DPM에서는 허용 가능한 최대 복구 지점 수보다 많은 수의 복구 지점을 만드는 보호 정책은 설정할 수 없습니다.
이 보호 구성을 사용할 경우 손실될 수 있는 파일 데이터의 양은 스냅숏이 만들어진 시기에 따라 달라집니다
IIS7 이상 버전을 사용하려면 Vista 또는 Server 2008을 써야 한다. 필자는 Vista만 써봤으므로 그것을 기준으로 하겠다.
※ Vista SP1부터는 IIS7 자체에 FastCGI 모듈이 내장되어 있으므로 그것을 쓰면 된다.
php.net에서 최신 PHP 버전을 받아 설치한다. (5.2 이상 버전 권장, 글 쓰는 현재 5.2.6이 최신 버전임)
이때 installer보다는 zip package를 권장하는데, 그 이유는 isntaller는 설치는 편리하지만 확장 기능(gd, mysql 등등)이 하나도 안 들어있기 때문이다. 나중에 zip package를 받아 확장기능 폴더만 복사해넣어도 되긴 하나 한 번에 하는 게 편하니까 zip package로 바로 하자.
Tips!
| http://hsshin.isblog.net/blog_post_101.aspx 쿨가이님 홈피에서 업어온거 |
 CGI(Common Gateway Interface)라는 단어는 웹이 유행하기 시작할 즈음부터, 많이 들렸던 단어입니다. 특정 클라이언트가 서버에 요청을 보냈을 때, 해당 요청을 처리하기 위해 응용 프로그램이 필요할 수 있습니다. 이 때 서버와 응용 프로그램 사이에 메시지를 주고 받기 위한 인터페이스를 CGI라고 표현합니다. IIS 6.0 시절 응용 프로그램을 통해서 서비스해야 했던 대표적인 것이 바로 PHP입니다. PHP 모듈을 다운로드받아, 설치하고, PHP에 대한 요청시 이를 PHP 모듈과 연결하여서 서비스하는 형태를 취해야 했습니다. PHP라고 하면, Linux + Apache 서버를 많이 생각하시게 되는데, IIS에서도 이를 서비스를 아예 못했던 것은 아닙니다. Microsoft의 기술은 항상 이기종 및 공존 환경에서도 최적의 솔루션이 될 수 있도록 생각하고, 이를 기술화시키고 있습니다. 그렇지만 IIS 6.0 + PHP는 서비스라는 가치를 제공하긴 했지만, 약간의 부족함이 보였습니다. 바로 성능적인 이슈입니다. PHP를 처리하기 위한 프로세스인 PHP-CGI.EXE의 프로세스가 한개 이상 생성이 안되었었고, 또한 요청시 프로세스 생성, 요청 처리 완료시 프로세스 종료를 시키는 형태였기 때문에, 대용량 & 많은 요청시 서버에서는 프로세스 생성, 종료를 위한 추가적인 부하가 걸렸었습니다. 이러한 부하가 대용량 처리에 한계에 이르렀고, PHP를 서비스하기 위해서는 IIS는 아니라는 생각을 가지게된 계기가 되었다고 생각합니다. IIS 7.0에서는 FastCGI라는 새로운 컨셉을 제공합니다. IIS 7.0뿐만 아니라 IIS 5.1, IIS 6.0에서도 이제 PHP를 Apache보다 더 나은 성능으로 제공합니다. 먼저 FastCGI라는 기술을 설명드리면, ZEND라는 회사에서 개발을 하였고, IIS 팀과의 긴밀한 협조속에 IIS 에서도 이를 마음껏 사용할 수 되었습니다. 원리는 간단히 이렇습니다. 1. 기존에 부하가 걸렸던 프로세스 생성/종료 문제를 해결하기 위해, IIS Worker Process와 마찬가지로, 요청시 생성되고, 바로 종료되지 않고 일정시간 대기 후, 요청이 없는 경우, 종료합니다. 2. 하나의 프로세스로 모든 걸 처리하려고 했던 아키텍쳐에서 요청 급증시 멀티 프로세스 모델로 변경  FastCGI를 사용하는 방법은 기존 IIS 6.0과 동일합니다. PHP 모듈을 다운로드받습니다. PHP 예제 샘플은 이미지 뷰어 공개 샘플인 QDIG을 사용하게 됩니다.
이제 PHP를 FastCGI내 처리기 매핑 처리를 해줘야 합니다. 사이트내 처리기 매핑에서 모듈 매핑 추가를 클릭합니다. 그런 후 나오는 창에서, 이 포스팅 가장 상단 그림의 내용을 입력합니다. 그러면 셋팅 끝입니다. :)   기본 문서에서 Index.PHP를 기본 문서로 잡는 것도 필요하겠죠.  IIS는 .NET을 구동시키기 위한 최상의 플랫폼임과 동시에, 조직내 이기종 환경에서도 이를 지원하는 최적화 플랫폼입니다. 이를 뒷받침하는 좋은 기술 중 하나가 바로 FastCGI가 되게 됩니다. 감사합니다. |
http://hsshin.isblog.net/blog_post_127.aspx 쿨가이님 홈피에서 업어온거
1. IIS7을 Windows Server 2003에 설치 가능한가요?
- 아니오, IIS7은 Windows Server 2008에서만 구동됩니다. 물론, Windows Vista SP1 버전에서 IIS7의 개발
자 버전이 구동되긴 합니다. 개발은 Vista의 IIS7에서 하고, 실제 운영은 Windows Server 2008의 운영서버에서 진행하는 형태가 가장 추천되는 시나리오 입니다.
2. IIS7을 커맨드를 이용해서 관리할 수 있나요?
- 물론 입니다. Appcmd.exe 라고 하는 "맥가이버 칼" 같은 도구로 IIS 관리자에서 수행 가능한 모든 작업을
커맨드라인으로도 수행할 수 있습니다.
3. IIS6에서 사용하던 ADSI, WMI를 IIS7에서도 사용할 수 있나요?
- 물론입니다. IIS6.0 관리 호환성을 설치하면 사용 가능합니다.
4. IIS7을 설치하기 위해 모든 기능 서비스, 모듈, 종속성(Dependency)에 대해 알아야만 하나요?
- 아는 것이 좋습니다. IIS 관리자(GUI) 방식을 사용하면 몰라도 설정이 일부 가능하긴 하지만, pkgmgr를 사용하여 설치하는 경우라면 정확히 알고 있어야, 혹시 발생할 지 모를 오류를 방지할 수 있습니다.
5. 모든 Feature를 인스톨하면 무슨 문제가 있습니까?
- 사실 문제가 있는 건 아니지만, IIS7.0의 사용하지 않는 기능을 메모리에 올라가게 하므로 메모리 Footprint가 증가되어 성능에 지장이 있고, 해킹 및 보안 위협에 대한 가능성을 높이며, 불필요한 패치 빈도를 높이는 결과를 초래할 수 있습니다.
6. 메타베이스가 사라졌다고 하는데, 왜 FTP 배포 서비스는 메타베이스를 찾는지 궁금합니다.
- 더 이상 메타베이스가 중심 저장소는 아니지만, FTP 배포 서비스는 IIS6.0과 달라지지 않았으므로 메타베이스가 존재하고 있다고 생각을 합니다. 하지만 IIS7은 모든 요청을 Applicationhost.config로 번역을 해주게 됩니다. 결국 메타베이스는 사용되지 않는 것이고, 리거시 어플리케이션과 Feature는 있다고 생각만 하는 것입니다.
7. 매니지드코드와 네이티브코드가 요청 파이프라인에 동일한 접근 권한을 가지는데, 왜 네이티브 코드를 사용하는 거죠?
- 성능 이슈 때문에 그렇습니다. 네이티브 코드(C++)는 오버헤드가 적습니다. 매니지드 모듈은 특정 어플리케이션에 맞도록 사용하는 목적, 네이티브 모듈은 글로벌하게 사용하는데 적절합니다.
8. ApplicationHost.config 파일은 서버 정보, Web.config 파일은 어플리케이션 정보를 담고 있습니다.
9. ApplicationHost.config 파일은 아무나 수정 가능합니까?
- 아닙니다. 윈도우 관리자만 수정 가능합니다.
10. Section Group이 뭐죠?
- 관련 섹션의 모음 입니다. 계층 구조로 이루어져 있습니다.
11. Location tag은 어떨 때 사용하는 것입니까?
- Locking 과 Unlocking 용도로 사용합니다. 관리 위임할 때
12. Appcmd.exe가 클라이언트에서 리모트 IIS7을 관리할 수 있습니까?
- 안됩니다. 리모트 관리(원격)를 위해서는 WMI를 사용하셔야 합니다.
13. 호스팅 업체에서 고객이 Trace 셋팅을 사용하고 싶습니다. 가능한가요?
- 네, 가능합니다. 하지만, 서버 내의 모든 고객이 Trace가 가능하도록 설정하는 것과 동일함을 고려해야 합니다.
14. Error 모듈을 교체 가능한가요?
- 네. 가능합니다. 사이트 레벨로 Error 모듈을 교체할 수 있고 IIS7의 확장성이 갖는 장점중의 하나입니다.
