Data Science Lab

IIS W3C Logging

-       Version : IIS

W3C 확장 로그 파일 형식은 추적된 정보를 커스터마이징하여 더 자세한 정보를 얻을 수 있다. 확장 로그 파일을 커스터마이징하려면 로깅하려는 필드를 선택한 후 서버에서 처리하도록 설정해야 한다. 그러면 액세스 로그에 저장되는 항목 크기가 증가되고 필드가 추가 되기 때문에 저장에 필요한 공간이 이전 형식에 비해 훨씬 늘어난다.

아래 스크립트는 W3C 로그의 일부이다. 다른 로그형식과는 다르게 빈 공간으로 항목을 구분한다.

확장 로그 파일 형식을 사용한 로그 항목을 처음 보면 파일 요청과 서버 지시어로 작성되어 있기 때문에 약간 혼라스러울 수 있다. 하지만 서버 지시어는 접두어로 해시 표시(#)가 붙기 때문에 실제 파일 요청과 쉽게 구분할 수 있다.

대부분 확장 로그 필드는 접두어를 가지고 있다. 접두어는 특정 필드가 사용된 방법이나 필드를 얻는 방법을 의미한다. 예를 들어, CS 접두어는 클라이언트에서 서버로 보내진 요청에서 필드를 얻었다는 것을 의미한다.

확장 로그에 저장되는 모든 필드는 필드 식별자를 가지고 있다. 이러한 식별자는 특별한 힐드 레코드의 정보 유형을 의미한다. 지정된 필드는 생성하려면 IIS 서버는 필드 접두어와 필드 식별자를 조합하거나 단순히 필드 식별자만 이용한다. 아래 표는 필드 식별자에 대한 설명이다.

[참고자료]

https://msdn.microsoft.com/en-us/library/ms525807(v=vs.90).aspx

2018-10-23 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, IIS log, IIS logging, IIS 로그 모니터링

IIS Logging

-       Version : IIS

IIS 로그 파일 형식은 고정된 ASCII 형식이다. 표준 ASCII 텍스트 형식으로 표시되기 때문에 모든 표준 텍스트 편집기나 호환 응용 프로그램을 통해서 로그를 확인할 수 있다. 아래 스크립트는 IIS 로그 파일의 내용이다. 각 항목은  쉼표로 구분된다.

[참고자료]

https://msdn.microsoft.com/en-us/library/ms525807(v=vs.90).aspx

2018-10-22 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, IIS log, IIS logging, IIS 로그 모니터링

IIS NCSA Logging

-       Version : IIS

NCSA 로그 파일 형식은 로그파일의 가장 기본적인 형식이다. NCSA 로그 파일 형식은 고정된 ASCII 형식이며 각 로그 항목은 고유 파일 요청을 나타낸다. 이 로그파일을 분석하면 아래와 같은 정보를 얻을 수 있다.

·       Hits (고유한 파일 요청 수)

·       Page views (고유한 페이지 요청 수)  

·       Visits (지정된 기간 동안 사용자 세션 수)

·       기타 기본적인 액세스 정보

NCSA 로그 파일 형식은 아래와 같은 항목을 포함하고 있으며 로그 항목 개수가 적기 때문에 로깅에 필요한 공간이 절약된다. 아래 샘플은 NCSA 형식으로 기록된 로그이다.

·       호스트 : 172.21.13.45

·       ID :

·       사용자 인증 : Microsoft\JohnDoe

·       타임 스탬프 : [07/Apr/2004:17:39:04 -0800]

·       HTTP 요청 유형 : "GET /scripts/iisadmin/ism.dll?http/serv HTTP/1.0"

·       상태 코드 : 200

o   1XX : 계속/프로토콜 변경

o   2XX : 성공

o   3XX : 리디렉션

o   4XX : 클라이언트 오류/실패

o   5XX : 서버 오류

·       전송 크기 : 3401 (단위 : byte)

[참고자료]

https://docs.microsoft.com/en-us/windows/desktop/http/ncsa-logging

2018-10-18 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, IIS log, IIS NCSA logging, IIS 로그 모니터링

IIS 액세스 로그 종류

-       Version : IIS

액세스 로그는 HTTP, FTP, SMTP 서버에서 로깅을 사용한다고 설정할 때 생성된다. 웹사이트에 요청이 있을때 마다 가저오려는 모든 성공, 실패 시도가 액세스 로그에 기록된다. 액세스 로그를 분석하면 아래와 같은 정보를 확인할 수 있다.

·       하루 혹은 한주의 가장 바쁜 시간

·       사이트에 방문하는 사용자의 사용 브라우저 및 플랫폼

·       리소스 선호도

·       어떤 사이트를 통해서 들어오는지

·       광고에 효과적인 정보 수집

·       검색 엔진 사용량 및 키워드에 대한 정보

·       사이트에 머문 시간

IIS에서는 아래와 같은 다양한 형식의 액세스 로그를 구성할 수 있다.

·       NCSA(National Center for Supercomputer Applications) 공통 로그 파일 형식 (웹 서버와 SMTP 서버만) : 기본적인 추적 및 보고서 기능이 필요할 때 NCSA 공통 로그 파일 형식을 사용한다. 이 형식을 사용하면 수집되는 로그 항목이 적기 때문에 저장에 필요한 공간이 크지 않다.

·       Microsoft IIS 로그 파일 형식 : 로그에 더 많은 정보를 저장하려고 할때 IIS 로그 파일 형식을 사용할 수 있다. 이 형식을 사용하면 꼭 필요한 로그 항목만 저장되기 때문에 로깅에 필요한 저장 공간이 절약된다.

·       W3C 확장 로그 파일 형식 : 추적되는 정보를 커스터마이징해야할 때 W3C 확장 로그파일 형식을 사용한다. 이 형식을 사용하면 로그 항목이 많아지기 때문에 저장소 공간이 많이 필요하다. 너무 많은 항목은 서버에 영향을 줄 수 도 있다.

·       ODBC 로깅 : 직접적으로 ODBC 호환 데이터베이스에 액세스 정보를 기록하려고 할때 사용. 수집되는 항목의 개수는 많지 않지만 표준 로그 파일보다 쉽게 데이터를 읽을 수 있다. ODBC 로깅은 로컬 데이터베이스 인스턴스에 직접 로깅하기 때문에 리소스를 많이 사용한다.

·       중앙 이진 로깅 : 서버에 여러 웹사이트가 운용되고 있을 경우 하나의 로그 파일에 로깅하려고 할때 사용. 이 로깅을 사용하면 로그 파일은 고정된 길이로 저장되며 .ibl 확장자를 사용하는 IBL(Internet Binary Log) 형식으로 기록되는 인덱스 레코드로 저장된다.  

2018-10-17 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, IIS 성능 카운터, IIS Performance counter, IIS 모니터링

IIS 프로세스 사용량 모니터링

-       Version : IIS

프로세스 사용량 관련 성능 카운터에 대해서 살펴 본다. CPU는 서버의 정보를 실제로 처리하는 역할을 한다. 서버의 성능을 검사할 때 메모리 병목현상을 제거한 후에는 CPU를 의심해 보아야 한다. 서버의 프로세서에 병목이 발생한다면 더 빠른 클럭이나 더 많은 수의 코어를 가진 CPU로 업그레이드를 고민해야 한다.

[쓰레드 큐]

·       System\Processor Queue Length : 실행 되기 위해 기다리는 쓰레드의 수를 표시한다. 이러한 쓰레드는 시스템의 모든 프로세스에서 공유하는 영역에 대기된다. 이 카운터가 Core 수 X 2 배수이상으로 지속되면 프로세서 업그레이드를 검토 해야한다.

[CPU 사용량]

·       Processor\%Processor Time : 프로세서가 비유휴 쓰레드를 실행하는데 소비한 시간의 퍼센트이며 서버의 모든 프로세서 인스턴스마다 별도로 추적해야 한다. 네트워크 인터페이스 및 디스크 I/O 처리량에 비해 %Processor Time 값이 높다면 프로세서 업그레이드를 검토해야 한다.

[ASP 성능]

·       Active Server Pages\Request Wait Time : 가장 최근의 요청이 큐에서 기다리는 밀리세컨드 수

·       Active Server Pages\Requests Queued : 처리되기 위해 기다리는 요청 수

·       Active Server Pages\Requests Rejected : 실행되지 않는 전체 요청 수. 요청이 실행되지 얂는 이유는 처리할 리소스가 없기 때문이다.

·       Active Server Pages\Requests/sec : 초당 실행된 요청 수

2018-10-15 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, IIS 성능 카운터, IIS Performance counter, IIS 모니터링

IIS 메모리, 캐싱 가상 메모리 사용량 확인

-       Version : IIS

IIS 메모리 사용량 관련 성능 카운터에 대해서 살펴 본다.

[실제 및 가상 메모리 사용량]

·       Memory\Available Kbytes : 컴퓨터에서 실행되는 프로세스에 할당하거나 시스템에서 사용할 수 있는 실제 메모리 크기 (킬로바이트)

·       Memory\Committed Bytes : 커밋된 가상 메모리의 크기 (바이트)

서버에서 사용할 수 있는 메모리가 거의 없으면 시스템에 메모리를 추가해야한다. 일반적으로 서버의 전체 실제 메모리의 5% 정도가 사용할 수 있는 메모리로 남아 있어야 한다. 시스템 전체의 실제 메모리에 대한 커밋된 바이트의 비율이 높다면 서버에 메모리를 추가해야한다. 일반적으로 커밋된 바이트 값이 전체 메모리의 75% 정도가 되어야 한다.

[메모리 캐싱]

·       Memory\Cache Bytes : 파일 시스템 캐시의 전체 크기를 바이트로 표시

·       Internet information Services Global\Current File Cache Memory Usage : IIS 파일 캐시에서 사용하는 현재 메모리 표시

·       Inter information Services Global\File Cache Hits% : 전체 캐시 요청 대비 캐시 히트율 (히트율이 높을수록 좋음)

·       Inter information Services Global\File Cache Flushes : 서버를 시작한 이후의 파일 캐시 플러시 수. 플러시가 너무 빨리 발생하면 ObjectCacheTTL 값을 증가시켜야 한다. 반대로 플러시가 너무 느리면 ObjectCacheTTL 값을 감소 시켜야 한다.

[메모리 페이징]

·       Memory\Pool Paged Bytes : 페이지 풀의 바이트

·       Memory\Pool Nonpaged Bytes :  페이지 되지 않은 풀의 바이트

페이지된 풀은 사용되지 않을 때 디스크에 쓰여질 수 있는 객체에 대한 시스템 메모리 영역이다. 페이지된 풀의 크기가 일반적으로 시스템의 실제 메모리의 전체 양과 비슷하다면 시스틈에 메모리를 추가해야 한다. 페이지되지 않은 풀의 크기가 서버에 할당된 가상 메모리의 전체 양과 비슷하다면 가상 메모리 크기를 늘려야 한다.

[메모리 페이지 부재]

·       Memory\Page Faults/sec : 초당 페이지 부재의 평균 수

·       Memory\Pages Input/sec : 하드 페이지 폴트를 해결하기 위해 디스크에서 페이지를 읽은 비율

·       Memory\Page Reads/sec : 하드 페이지 부재를 해결하기 위해 디스크를 읽은 비율

페이지 부재는 프로세스가 메모리의 페이지를 요청했을 경우에 시스템에서 요청된 위치를 찾을 수 없을 때 발생한다. 요청된 페이지가 메모리의 어딘가에 있다면 이 부재를 소프트(soft) 페이지 부재라 한다. 그리고 요청된 페이지를 디스크에서 가져와야 한다면 하드(hard) 페이지 부재라고 한다. 대부분의 프로세서는 많은 수의 소프트 페이지 부재를 처리할 수 있지만 하드 페이지 부재인 경우 성능이 느릴수 있다. 만약 하드 페이지 부재가 많이 발생한다면 메모리 양을 늘리거나 캐시 크기를 줄여야 한다.

IIS에서 사용하는 메모리는 MemCacheSize와 MaxCachedFileSize 레지스트리 설정으로 제어할 수 있다. 그러나 이러한 항목이 수동으로 추가되지 않는다면 값은 레지스트리의 기본값을 사용한다.

2018-10-10 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, IIS 성능 카운터, IIS Performance counter, IIS 모니터링

IIS 성능 카운터

-       Version : IIS

IIS 성능을 모니터링 하기 위한 방법으로 성능 도구 중의 하나인 성능 카운터(Performance Counter)가 있다. IIS가 설치되면 수 백개의 성능 카운터가 추가되며 카운터는 객체에 따라 그룹으로 구분되어 있다. 아래 목록은 IIS 모니터링에 중요한 성능 카운터 목록이다.

·       ASP.NET : ASP.NET 응용프로그램, 응용프로그램 요청, 작업자 프로세스의 일반적인 추적 객체 카운터

·       ASP.NET Applications : ASP.NET 응용프로그램 큐 및 기타 지정된 ASP.NET 응용 프로그램 카운터를 추적하는 객체 카운터

·       Active Server Pages : 서버에서 실행되는 ASP 스크립트 및 응용 프로그램에 대한 객체 카운터

·       FTP Service : FTP 서비스의 객체 카운터

·       Indexing Service : 인덱싱 프로세스, 단어 목록, 쿼리와 관련된 인덱싱 서비스의 객체 카운터

·       Indexing Service Filter : 필터와 관련된 컨텐츠 필터 및 인덱싱 속도와 관련된 추가 성능을 제공하는 객체 카운터

·       Internet Information Services Global : 서버에서 실행되는 모든 인터넷 서비스(WWW, FTP, SMTP, NNTP 등)에 대한 객체 카운터

·       NNTP Commands : 사용자가 서버에서 실행하고 있는 NNTP 명령어와 관련된 객체 카운터

·       NNTP Server : 초당 게시물 전송, 수신, 게시 수와 같은 전체 NNTP 성능을 추적하는 객체 카운터

·       SMTP NTFS Store Driver : 메시지 및 메시지 스트림의 전채 개수를 추적하는 객체 카운터

·       SMTP Server : 초당 수신 및 송신 메시지 수와 같은 전체 SMTP 성능을 추적하는 객체 카운터

·       Web Service : World Wide Web Publishing Service의 객체 카운터

·       Web Service Cache : 메타데이터, 파일, 메모리, URI(Uniform Resource Identifiers)를 포함하는 웹 서비스에서 사용되는 캐시의 자세한 정보를 제공하는 카운터

2018-10-09 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, IIS 성능 카운터, IIS Performance counter, IIS 모니터링

IIS 액세스 로그 설정

-       Version : IIS

IIS는 IIS액세스 로그와 Windows 이벤트 로그에서 오류를 기록한다. IIS 설정에서 Web, FTP SMTP, NNTP에서 로그를 기록하도록 설정하였으면 액세스 로그가 생성될 것이다. 사용자가 사이트의 파일을 요청할 때마다 액세스 로그에 기록되고 리소스 요청 히스토리가 만들어진다. 항목마다 상태 코드를 포함하기 때문에 요청이 성공했는지 실패했는지 판단할 수 있다.

특정 사이트에 대한 액세스 로그를 보려면 아래 순서를 따라 설정한다.

IIS(Internet Information Services) Manager를 실행한다.

Web, FTP, SMTP, NNTP 등 액세스 로그를 남기려는 사이트를 클릭하고 Logging 아이콘을 더블클릭한다.

로그는 다양한 포맷으로 남길 수 있으며 로그를 남기려는 필드 또한 선택이 가능하다.

[로그 파일 디렉터리] 필드는 이 사이트 로그에 대한 최상위 디렉터리를 표시한다. 기본 최상위 디렉터리는 “%SystemDrive%\inetpub\logs\LogFiles”이다.

로그는 위에 말한것 처럼 로그 파일에 기록하거나 윈도우 이벤트 로그에 기록 또는 양쪽 모두에 기록 할 수 있다.

로그파일은 특정 크기 또는 특정일 간격으로 롤오버하여 기록할 수 있다.

로그 폴더에서 기록된 로그를 확인할 수 있다.

2018-10-08 / Sungwook Kang / http://sqlmvp.kr

Windows, IIS, 웹서버, 윈도우 웹서버, 액세스 로그, IIS Log, Access log, Web log

브라우저 요청 리디렉트 하기

• Version : Windows Server 2012 R2

리디렉트는 요청에 대한 경로를 새로운 경로 값으로 지정하는 것으로 브라우저 리디렉션은 웹 사이트 내에서 컨텐츠의 이름을 바꾸거나 삭제하는 경우 기존 사이트에 대한 오류가 발생하지 않도록 다른 사이트로 연결할 때 매우 유용하다.

리디렉트 기능으로는 다음과 같다.

• 다른 디렉터리의 파일 검색
• 다른 웹 사이트의 파일 검색
• 다른 컴퓨터의 파일 검색
• 여러 파일 대신 지정된 파일 검색
• 요청된 파일에 접근하는 대신, ISAPI 응용 프로그램 실행

리디렉션을 하려면 웹서버에 [HTTP 리디렉션]기능이 설치되어있어야 한다.

HTTP 리디렉션 설치가 완료되면 IIS 관리자에서 리디렉트하려는 웹사이트를 선택하고 [HTTP 리디렉션]을 클릭한다.

[HTTP 리디렉션] 관리에서 연결하려는 주소를 입력하고 적용을 클릭한다.

적용이 완료되면 기존 사용하던 주소를 입력하면 자동으로 리디렉션 주소로 이동하여 해당 사이트로 연결되는 것을 확인할 수 있다.

웹 사이트에서 리디렉션을 할 때 응용프로그램으로 리디렉션도 가능하다. 이때 리디렉션 변수를 사용하여 응용프로그램에 필요한 파라메터를 포함할 수 있다.

[참고자료]

http://www.iis.net/configreference/system.webserver/httpredirect

2016-03-11 / 강성욱 / http://sqlmvp.kr

Windows, IIS, 웹서버, 윈도우 웹서버, 리디렉션, Redirection, HTTP Redirects, IIS 서버

Incoming connection 제한과 Time-Out 값 설정

• Version : Windows Server 2012 R2

IIS 웹서버를 운영할 때 웹사이트로 들어오는 연결(incoming connection)을 제어하는 방법에 대해서 알아본다. IIS 서버는 들어오는 연결에 대해서 동시 연결 수 제한 및 연결 타임아웃(time-out) 값을 제어할 수 있다.

보통 웹사이트가 수락하는 연결의 수는 무제한이며 대부분의 환경에서는 이러한 설정이 최적의 설정이다. 그러나 너무 많은 수의 연결이 있는 경우 웹 사이트의 성능이 감소되어, 최악의 경우 웹사이트의 접속이 불가능할 수도 있다. 이러한 사태를 방지하려면 동시 연결의 수를 제한해야 한다. 동시 연결 수가 제한에 달하면 그 이후의 클라이언트들은 서버로의 액세스가 거부된다. 이 경우 서버의 부하가 줄어들 때까지 새로운 클라이언트들은 대기 해야 한다. 물론 현재 접속되어 있는 사용자는 계속 사이트를 탐색할 수 있다.

연결 타임아웃은 유휴(idle)사용자 세션이 끊기는 제한 시간이다. 기본 웹 사이트에서는 유휴 상태가 120초(2분) 간 지속되면 연결이 끊긴다. 타임 아웃 설정은 브라우저가 올바르게 종료되지 않은 경우에 연결이 계속 열린 상태로 유지되는 일을 예방한다.

최대 동시 연결 및 연결 시간 제한을 수정하는 방법은 IIS 관리자에서 제어할 수 있다. IIS 관리자를 실행하여 연결 및 타임아웃을 수정하려는 웹사이트를 선택 한다. 그리고 마우스 오른쪽을 클릭하여 [웹사이트 관리] – [고급 설정]을 클릭 한다.

[고급 설정] 팝업 창이 나타나면 하단의 [제한] 메뉴를 확장하여 연결 시간 및 최대 동시 연결 수를 수정한다.

연결 시간 제한 및 최대 연결 수에 대한 최적의 값은 시스템마다 다르다. 서비스하는 시스템의 성능을 꾸준히 모니터링 하여 최적의 임계값을 찾아 적용할 수 있도록 한다.

2016-02-25 / 강성욱 / http://sqlmvp.kr

IIS Server, IIS 웹서버, 웹서버 타임아웃, 웹서버 연결 제한, IIS Time out, Windows Server, 웹서비스, 웹사이트

IIS (Internet Information Services) 설치

• Version : Windows Server 2012 R2

Windows 환경에서 웹서비스를 하기 위한 IIS 설치 방법에 대해서 알아본다. Windows Server (또는 개인용에서 특정 에디션에서 추가 가능)에서 추가 기능으로 설치할 수 있는 IIS(웹서버) 역할은 웹 사이트, 서비스 및 응용프로그램을 안정적으로 호스팅하기 위한 관리 모듈식 플랫폼을 제공한다. Windows Server 2012에서 제공되는 IIS 8 버전은 IIS, ASP.NET, FTP 서비스, PHP 및 WCF(Windows Communication Foundation)를 통합하는 통합형 웹 플랫폼이다.

IIS를 설치(기능추가)하기 위해서 서버관리자를 실행한다. 상단 메뉴에서 [관리]-[역할 및 기능 추가]를 클릭하여 마법사를 실행할 수 있도록 한다.

역할 및 기능 추가 마법사가 실행되면 [다음]을 클릭하여 설치를 진행 한다.

설치 유형에서 [역할 기반 또는 기능 기반 설치]를 선택하고 [다음]을 클릭하여 진행한다.

대상 서버 선택에서는 [서버 풀에서 서버 선택]을 선택하고 자신의 서버 이름이 나타나면 선택한다.

서버 역할 선택에서 [웹 서버(IIS)] 항목을 체크한다.

[웹 서버(IIS)를 선택하면 웹 서버 설치에 필요한 기능을 추가하는 팝업창이 나타난다. [관리도구 포함]을 선택하고 [기능 추가]를 클릭한다.

서버 역할 선택에서 [웹 서버(IIS)] 선택이 완료 되었으면 [다음]을 클릭하여 설치를 진행 한다.

기능 선택에서는 닷넷 프레임웍(.NET Framework) 3.5를 선택하여 추가 설치할 수 있도록 한다.

웹서버 역할에 대한 정보가 나타나면 [다음]을 클릭하여 설치를 진행 한다.

역할 서비스 선택에서는 웹서버에서 설치할 상세 기능들을 선택한다. 웹서비스를 분석하기 위해서는 성능, 보안 등 로깅을 남길 수 있도록 선택하여 설치 한다. 기능 선택이 완료 되었으면 [다음]을 클릭하여 설치를 진행 한다.

설치 선택 확인에서는 설치할 목록을 요약하여 나타내며 시스템 재시작이 필요할 경우 자동으로 재시작 여부를 선택할 수 있다. 설치 프로그램이 없을 경우 상단에 노란색으로 경고를 나타낸다. 실습에서는 닷넷 프레임웍 3.5 요구사항에서 오류가 발생하여 [대체 원본 경로 지정]을 클릭하여 미리 다운로드 받은 닷넷 프레임웍 3.5 경로를 지정해서 해결할 수 있었다.

요구사항 확인이 완료 되면 기능이 설치되며 설치 과정을 확인할 수 있다.

설치시 필요한 파일이 없거나 예기치 못한 오류가 발생하면 아래 그림과 같이 실패 결과를 반환한다. 오류 사항을 확인하여 해결한 다음 다시 설치를 할 수 있도록 한다.

설치가 완료되면 윈도우에서 설치된 프로그램 목록에서 IIS(인터넷 정보 서비스) 관리자가 설치된 것을 확인할 수 있으며 IIS 설정 및 구성에 대한 모든 부분을 해당 프로그램을 통해 설정할 수 있다.

[참고자료]

https://technet.microsoft.com/ko-kr/library/hh831725.aspx

2016-02-22 / 강성욱 / http://sqlmvp.kr

Windows Server 2012, IIS, 윈도우 웹서버, Internet Information Services, iis 서버, 웹서버, ASP. ASP.NET, iis 설치, 웹서버 설치

Windows 작업 관리자 표시 항목 추가

작업관리자의 프로세스 탭의 항목을 추가하여 다양한 정보를 확인 하는 방법을 알아 보자.

작업 표시줄에서 마우스 오른쪽을 클릭하여 [작업관리자 시작(K)]를 선택한다.

작업관리자가 실행되면 다음과 같이 프로세스 탭으로 이동 한다.

현재 실행되고 있는 모든 사용자 프로세스를 확인하고 싶다면 하단의 체크 박스를 클릭하여 옵션을 활성화 한다.

 

프로세스 탭에서 현재 나타내고 있는 정보 외에 추가로 정보를 확인하고 싶다면 [보기] -[열 선택]을 클릭 한다.

[프로세스 페이지 열 선택] 창이 나타나면 확인하려는 항목을 선택한다. 실습에서는 [메모리 - 페이징 풀]을 추가해 보기로 한다.
 

작업 관리자의 프로세스 탭에서 페이징 풀 정보가 나타난 것을 확인 할 수 있다.

원격 접속 후 접속 리스트 삭제 하기 (RDP 기록 삭제)

최근 들어 원격 지원으로 작업하는 이슈가 자주 발생 하였다. 외부에서공용의 컴퓨터(PC방, 다른 컴퓨터 등)에서 원격 접속을 하였을 때 접속 주소에 대한 기록이 남아 있어 불안 할 때가 있다. 다음 과정을 통해서 내가 접속했던 원격 접속의 기록을 삭제 하자.

[시작] – [실행] – [mstsc] 또는 [원격 데스크톱]을 실행하면 예전에 접속했던 기록들이 남아 있다. 혹시나 해킹에 대한자료로 쓰일 수 있기 때문에 불안하다. 삭제하자!

접속 기록에 대한 내용은 레지스트리에 저장되므로 레지스트리의 정보를 삭제 한다.

[시작] – [실행] – [regedit]를 실행 한다.

레지스트리 편집기에서 다음 위치로 이동 한다.

그리고 접속 기록을 모두 레지스트리에서 삭제 한다.

내문서에서 RDP의 정보를 삭제 하는데 이 때 파일이 숨겨져 있으므로폴더 옵션에서 숨겨진 파일을 볼 수 있도록 설정 변경 후 삭제 한다.

작업이 완료 되었으면 원격 접속을 실행 하여 보자. 지금까지 접속했던기록이 삭제된 것을 확인 할 수 있다.

Windows Server 2012 디스크 유틸리티 활성화

• Version : Windows Server 2012, 2012 R2

Windows Server 2012에서 디스크 유틸리티를 활성화 시키는 방법에 대해서 알아 본다.

윈도우 7에서 디스크 정리(임시파일 및 업데이트 백업 파일 삭제 등)가 필요한 경우 해당 드라이브를 선택하고 마우스 오른쪽 버튼을 클릭하면 [디스크 정리] 항목이 있어 쉽게 디스크를 정리 할 수가 있다.

Windows Server 2012에서는 기본적으로 이 기능이 활성화 되어 있지 않다.

서버 관리자에서 [역할 및 기능 추가]에서 해당 기능을 추가하여야 한다. 서버 관리자를 실행하고 [역할 및 기능 추가]를 실행 한다.

역할 및 기능 추가 마법사에서 [기능] – [사용자 인터페이스 및 인프라] – [데스크톱 경험]을 선택한다.

데스크톱 경험을 선택하고 시스템을 재시작 한다. (반드시 시스템을 재시작 해야 적용 되므로 운영 서버에서는 주의한다.) 시스템이 재시작 되면 다음과 같이 디스크 정리가 활성화 된 것을 확인 할 수 있다.

[참고자료]

• http://social.technet.microsoft.com/wiki/contents/articles/15221.enabling-disk-cleanup-utility-in-windows-server-2012.aspx

2014-08-18 / http://sqlmvp.kr / 강성욱

Windows Sever 2012, 디스크 정리, 윈도우 업데이트 파일 삭제, Windows Server 디스크 정리, 윈도우 서버 임시 파일 삭제, 임시 파일 삭제, Windows Server Disk Utility, 디스크 정리 유틸리티

Active Directory 구성

테스트 목적으로 필요해서 기본 세팅 정도의 AD 서비스가 필요하여 마법사를 통한 Active Direcotry 구성에 대해서 살펴 본다.

[시작] - [실행] 또는 [윈도우키] + [R]을 실행하여  [dcpromo] 입력

Active Direcotry 도메인 서비스 파일이 설치되어 있는지 확인 과정이 진행 된다.

설치 마법사가 실행되고 Active Directory 설치를 시작 한다.

호환성에 대한 경고 구문이 나타나는데 가볍게 읽고 넘어 간다. (현재 테스트 중인 운영체제는 Windows Server 2008R2 버전임)

배포 구성에 [새 포리스트에 새 도메인 만들기]를 선택 한다.

포리스트에 사용할 도메인 명을 입력한다.

입력한 이름이 다른 곳에서 사용중인지 확인 과정이 나타난다.

NetBios 명명 규칙에도 적합한지 확인

포리스트 수준을 설정 한다. 운영체제 버전별로 다양한 선택을 할 수 있다..

필자는 Windows Server 2008 R2 선택

추가 도메인 컨트롤러 옵션에  DNS를 체크.

고정 IP를 사용하였으므로 고정IP 주소 할당을 선택.

DNS 구성 검사 프로세스가 진행 된다.

경고 구문이 나타나지만 [예]를 선택 한다.

기본값 그대로 사용.

도메인 관리자 암호를 설정.

지금까지 설정한 요약정보가 나타난다.

도메인 구성 중.

도메인 설치가 완료 되었다.

컴퓨터 속성에서 보면 도메인이 설정된 것을 확인 할 수 있다.

혹시 도메인 설치 과정 중 다음과 같은 오류가 발생 한다면..

아래 그림처럼 실행하면 해결 가능 하다.

net user administrator(계정) / passwordreq:yes

Active Direcotry 구성에 대해서 살펴 보았는데 실제로 AD 구성은 매우 까다롭고 복잡한 시스템이다. 실제 현업에서는 전문 자료를 참고하여 최적의 세팅을 구성 할 수 있도록 한다.

Windows Server 2008(R2)작업 스케줄 만들기

 

- windows server 2008, windows server 2008R2, 윈도우, 윈도우서버, 윈도우 서버 2008, 윈2008, 작업 스케줄러, 예약작업, 윈도우 예약작업. 마이크로소프트

일정 시간에 실행해야 할 작업들을 윈도우 스케줄러에 등록하여 사용하자.

사전 준비 사항.

-      복사할 파일 원본을 가지고 있는 원본 서버의 연결이 정상 적인지 확인 한다.

-      작업 스케줄에 등록할 배치 파일을 생성 한다. (NET 명령어는다른 포스팅을 참고)

[시작] – [관리도구] –[작업 스케줄러]를 실행 한다.

작업 스케줄러 창이 나타나면 다음과 같이 [작업 만들기]를 선택 한다.

[새 작업 만들기]에서작업의 이름과 이를 실행할 계정을 등록 한다. (보안 정책에 따라 다르지만 최대한 로컬의 최고 권한으로실행하는 것이 나중의 권한 변경으로 인한 작업 실패를 예방 할 수 있다.)

[트리거] 탭에서 [새로 만들기]를 선택 한다. 트리거탭은해당 작업의 예약일정을 설정 할 수 있다.

[새 트리거 만들기] 창이나타나면 작업 일정을 설정 한다. 매일 또는 매주, 매월, 시간, 분 단위로 반복 작업 등 다양한 설정이 가능 하다.

맨 밑의 [사용] 박스에체크표시가 되어 있어야 트리거가 작동 한다.

트리거 생성을 완료하면 다음과 같이 생성된 트리거 목록을 확인 할 수 있다.

[동작] 탭에서 새로 만들기를선택 한다.

[새 동작 만들기] 탭이나타나면 동작 유형을 지정하고 동작할 파일의 경로를 지정 한다.

동작 생성을 완료하면 다음과 같이 생성된 동작 작업 목록을 확인 할 수 있다.

사용자 필요에 따라 조건, 설정, 기록탭에서 부가 설정을 한다.

작업 등록이 완료 되면 다음과 같이 작업 리스트를 확인 할 수 있다.

예약 시간을 수정하여 해당 시간에 확인해도 되고 다음과 같이 강제로 실행도 가능하다.

대상 서버에 있는 텍스트 파일이 정상적으로 복사된 것을 확인 할 수 있다.

데이터베이스 백업파일이나 1일 모니터링 정보 등을 수집할 때 몇 대의서버 정도는 수동으로 수집 할 수 있지만 관리하는 서버가 수십 또는 수백대라면 다음과 같은 작업을 등록하여 한번에 복사하여 사용하면 매우 효율적일듯 하다.

2012-08-31 / 강성욱 / http://sqlmvp.kr 

Windows Vista / Windows7 / Windows Server 2008(R2) MS DTC 설정

MS DTC ?

DTC(Distributed Transaction Coordinator) 서비스는 데이터베이스, 메시지 큐, 파일 시스템 등 두 가지 이상의 트랜잭션 보호 리소스를 업데이트하는 트랜잭션을 조정한다. 단일 환경의 컴퓨터나 또는 네트워크 상에 있는 분산환경의 컴퓨터들의 트랜잭션 리소스를 보호한다.

관련 링크 :  http://technet.microsoft.com/en-us/library/cc759136(WS.10).aspx

Raid Level

데이터 베이스의 성능은 쿼리를 얼만큼 효율적으로 잘 만드느냐!

옵티마이져를 얼마나 이해해서 최적의 수행경로를 찾느냐로 성능을 향상 시킬 수 있습니다.

하지만 소프트웨어는 하드웨어에 종속적이므로 하드웨어 성능 자체가 느리다면 아무리 튜닝을 해도 한계가 있기 마련입니다.

컴퓨터에서 가장 느린 장치가 무엇일까요?

하드 디스크 입니다. 이번 시간은 하드디스크를 여러 개 묶어서 성능을 향상시키는 방법에 대해 알아 보겠습니다.

RAID는Redunadant Array of Inexpensive Disks 의 약자로 값싼 디스크를 여러장 묶어 대용량의 저장공간을 만들고자 하는 요구로1980년대 처음 등장하였습니다. 최근에는 디스크 가격이 고용량 저가격이 형성되면서 의미는 많이 퇴색해져 중복성과 성능향상으로 바뀌고 있습니다.

RAID는 구성에 따라 총6가지(0, 1, 2, 3, 4, 5, 6)레벨로 나눌 수 있으며 레벨에 따라 신뢰성과 성능 향상을 나타냅니다.

RAID 0

2개 이상의 디스크를 사용하여 구성. 스트라이핑 모드.

장점: 같은 섹터에 병렬기록, 읽기/쓰기 향상.

단점: 디스크 장애시 복구 불능.

사용처: 중요하지 않는 데이터에 빠른 처리가 요구될 때 사용.

RAID 1

동일한Raid 볼륨으 추가적으로 구성 한 것. 미러링 모드

장점: 디스크 장애시 복구 가능. 읽기 성능 향상.(다중 스레드 사용시)

단점: 동일 데이터를 중복해서 써야하므로 쓰기 속도 느림.

사용처: 속도보다는 안정성을 추구하는 데이터에 적합. 전체용량의1/2 만 사용가능.

RAID 2

RAID 0의 장점을 사용하면서 신뢰성을 높이기 위한 방법. 4개를 스트라이핑 모드 구성+ 3개의 패리티 체크 구성.

장점: 여러 개의 디스크 장애시 복구 가능.

단점: 볼륨 구성 단위가 크다.

RAID 3

RAID2의 단점을 개선 한 모델. 하나의 볼륨에만 패리티 저장.

장점: RAID2보다 적은 볼륨 사용.(디스크 절약)

단점: 동일 위치 동시 장해시 복구 불능.

RAID 4

구성은RAID3와 동일. 단 저장 단위가RAID3는 바이트 단위. RAID4는 블록 단위.

<v></v>

RAID 5

RAID4의 단점을 개선 시킨 모델. 성능샹 효율을 위해 패리티 디스크들을 각 볼륨에 분할.

최소3개의 디스크 필요.

장점: 어느 정도 속도 보장.

단점: 다중 디스크 장애시 복구 불능. (1장 까지 장애 복구 가능)

RAID 6

RAID5에 비해 신뢰성에 기반을 둔 레벨. 패리티 디스크를 추가함으로써 동시 오류에 복구가 가능하도록 설계.

추가적인 패리티 기록을 위하여 속도가 느리다.

최근에는 하이브리드 방식으로RAID레벨의 장점을 섞어 성능과 신뢰성 비용 효과를 보고 있다.

-       RAID 0+1

-       RAID 1 + 0

-       RAID 5 + 0

-       RAID 5+ 1

-       RAID 6 + 0

RAID Level Comparision (Adaptec 자료)

익스큐티브 인터락드 동작

• Windows Server 2008

커널은 단일 링크드 리스트나 이중 링크드 리스트에 추가, 삭제 같은 좀 더 향상된 동작을 위해 스핀락을 기반으로 하는 간단한 동기화 함수를 여럿 제공한다. 이러한 모든 함수는 인자로 표준 스핀락을 필요로 하며 커널과 디바이스 드라이버에 의해 사용된다.

이들 함수는 스핀락 인자를 획득하고 해제하기 위해서 표준 API에 의존하지 않고 필요한 코드를 인라인으로 두며 상이한 순서 스킴(ordering scheme)을 사용한다. 반면 Ke 스핀락 API는 먼저 락이 해제 되었는지 보기 위한 비트를 테스트하고 설정한 다음에 실제로 획득을 하기 위한 락드 테스트 앤드 셋 동작을 원자적으로 수행한다.

이들 루틴은 프로세서의 인터럽트를 비활성화시키고 즉시 원자적 테스트 앤드 셋 연산을 수행한다. 초기 시도가 실패한다면 인터럽트는 다시 활성화 되고 테스트 앤드 셋 동작이 0을 반환할 때(이 경우 함수 전체가 다시 재시작 한다)까지 표준 비지 대기 알고리즘이 계속 된다.

미묘한 차이점으로 인해 익스큐티드 인터락드 함수에 사용되는 스핀락은 앞서 설명한 표준 API 커널과 함께 사용될 수 없다. 원래 비인터락드 리스트 연산은 인터락드 연산과 혼용해서는 안된다. 특정 익스큐티브 인터락드 연산은 가능한 경우 표시나지 않게 스핀락을 실제로 무시한다.

[참고자료]

Windows Internals

강성욱 / http://sqlmvp.kr

인스택 큐드 스핀락(InStack Queued SpinLock)

• Windows Server 2008

인스택 큐드 스핀락은 서드파티 개발자들이 스핀락을 사용할 수 있도록 한다. KeAcquireInstackQueuedSpinLock과 KeReleaseInstackQueuedSponLock 함수로 동적으로 할당되는 큐드 스핀락을 사용한다.

전역 정적 큐드 스핀락이 낭비라고 판단되는 경우 캐시 관리자와 익스큐티브 풀 관리자, NTFS 등의 여러 구성 요소가 이들 락 유형을 이용한다.

KeAcquireInstackQueuedSpinLockdms 인자로 스핀락 데이터 구조체의 포인터와 스핀락 큐 핸들을 가진다. 커널은 이 데이터 구조체에 락 소유권과 락이 이용가능하기를 기다리는 프로세서의 큐 등의 락 상태 정보를 저장한다. 이런 이유로 핸들은 전역 변수가 될 수 없다. 핸들은 일반적으로 스택 변수로서 호출자 스레드에 대한 지역성을 보장한다.

[참고자료]

Windows Internals

강성욱 / http://sqlmvp.kr

큐드 스핀락(Queued SpinLock)

• Windows Server 2008

스핀락의 확장성을 증대 시키기 위해 대부분의 상황에서 표준 스핀락이 아닌 큐드 스핀락(Queued Spinlock)형식이 사용된다.

• 스핀락 : http://sqlmvp.kr/140201377685

큐드 스핀락은 프로세서가 현재 소유된 큐드 스핀락을 획득하고자 할 때 프로세스는 스핀락 과 연관된 큐에 자신의 식별자를 둔다. 스핀락을 소유중인 프로세서가 스핀락을 해제할 때 프로세서는 큐에 지정도니 첫 번째 프로세서에게 락을 넘겨준다. 이 동안에 비지 스핀락을 대기하는 프로세서는 스핀락 자체의 상태가 아닌 프로세서마다의 플래그 상태를 검사한다.

큐드 스핀락은 전역 스핀락이 아닌 프로세서마다의 플래그 검사를 위해 스핀하기 때문에 두 가지 장점이 있다.

• 멀티프로세서 버스에서 프로세서간의 동기화로 인한 심각한 트래픽이없다.
• 스핀락 획득을 위한 대기하는 프로세서 그룹에서 임의의 프로세서가 락을 획득하는 대신 큐드 스핀락은 락 획득순거가 FIFO방식으로 강제된다. FIFO 순서는 동일한 락에 접근하는 프로세서 간에 좀 더 일관적인 성능을 유지한다.

윈도우는 각 프로세서의 프로세서 영역 제어 블록(PCB)에 포함된 배열에 전역 큐드 스핀락에 대한 포인터를 저장함으로써 다수의 전역 큐드 스핀락을 정의한다. 전역 스핀락의 수는 운영체제 릴리즈 버전마다 다르며 (증가하고 있음) 전역 스핀락에 대한 인덱스 정의표는 WDK헤어파일인Ntddk.h에 있다.

디바이스 드라이버는 큐드 스핀락을 획득하는 것이 지원되지 않으며 락 커널 내부 용도로 예약되어 있다.

[참고자료]

• Windows Internals
• Queued Spin Locks :

http://msdn.microsoft.com/ko-kr/library/windows/hardware/ff559970(v=vs.85).aspx

• http://www.cs.albany.edu/~sdc/CSI500/Fal11/Labs/Modules/WaitingRight.html

강성욱 / http://sqlmvp.kr

스핀락(SpinLock)

• Windows Server 2008

스핀락은 멀티프로세서 상호배제를 달성하기 위해 커널이 사용하는 메커니즘이다. 어느 한쪽 임계 영역으로 진입하기 전에 커널은 보호 DPC 큐와 관련된 스핀락을 획득해야 한다. 스핀락이 프리(free) 상태가 아니라면 커널은 획득에 성공할 때까지 계속 시도한다. 스핀락의 이름은 커널이 락을 얻을 때까지 돌면서(spinning) 대기하는 것에서 유래 했다.

스핀락은 자신이 보호하는 데이터 구조체처럼 시스템 주소 공간에 매핑된 넌페이지드 메모리에 존재한다. 스핀락을 획득하고 해제하는 코드는 속도 측면과 하부의 프로세서 아키텍처가 제공하는 락 메커니즘을 이용하기 위해 어셈블리로 작성 된다. 스핀락은 운영체제의 스케줄링 지원을 받지 않기 때문에 해당 스레드에 대한 문맥 교환이 일어나지 않는다.

첫 번째 스레드가 변수를 테스트하고 락을 획득하는 사이에 두 번째 스레드가 락을 가로채 가는 것을 방지 한다. 윈도우에서 모든 커널모드 스핀락은 DPC/디스패치 레빌이나 그 이상의 레벨과 관련된 IRQL을 가진다. 따라서 스레드가 스핀락 획득을 시도하면 스핀락 IRQL 또는 더 낮은 IRQL의 모든 다른 행위는 해당 프로세서에서 중지 된다. 스레드 디스패칭은 DPC/디스패치 레벨에서 일어나기 때문에 스핀락을 소유한 스레드는 절대로 선점되지 않는다.

스핀락을 소유하는 동안 커널은 실행명령 수를 최소화 하도록 매우 신중하게 스핀락을 사용한다. 스핀락 획득을 시도하는 모든 프로세서는 실제로 매우 바쁠(busy)것이며 무한히 대기하고 또한 전력을 소비(busy wait는 CPU 100% 사용량을 차지 한다.)하지만 실질적인 작업은 수행하지 않는다.

스핀락은 아직 잠금을 확보하지 않은 경우에도 스레드의 시간 간격을 계산할 수 있다. 이는 스레드 우선 순위 반전을 방지하고 가비지 수집기가 작업을 진행 할 수 있도록 하기 위한 것이다.

스핀락은 유저 프로그램이 사용할 수는 없다. 모든 경우 인터럽트 스핀락으로 보호받는 코드는 극히 짧은 시간 동안만 실행해야 한다. 조금의 지연이라도 생긴다면 일반적인 인터럽트 지연보다 클 수 있으며 성능에 좋지 않은 심각한 영향을 줄 수 있다.

커널 스핀락은 자신을 사용하는 코드에 제약을 수반한다. 스핀락은 DPC/디스패치 레벨이나 그 이상의 IRQL을 항상 갖기 때문에 스핀락을 소유하는 코드가 스케줄러로 하여금 디스패치 동작을 하게 하거나 페이지 폴트를 유발하면 시스템이 크래시 된다.

다중 코어 컴퓨터에서 대기 시간이 짧을 것으로 예상되고 경합이 적으면 다른 종류의 잠금보다 스핀락을 수행하는 것이 효과적이다. 스핀락은 지정된 시간에 잠금을 유지하는 스레드를 추적하기 위해 스레드-추적 모드를 지원한다. 이는 디버깅시 매우 유용하지만 성능을 저하시킬 수 있다.

[참고자료]

• Windows Internals
• SpinLock : http://msdn.microsoft.com/ko-kr/library/dd997366(v=vs.110).aspx

강성욱 / http://sqlmvp.kr

객체구조 – 객체 유지

• Windows Server 2008

객체 유형에는 임시 객체와 영구 객체가 있다. 임시객체는 사용중인 동안만 존재하며 더 이상 필요가 없을 때 해제 된다. 영구 객체는 명시적으로 해제 될 때까지 존재한다. 대부분의 객체는 임시 객체이다.

객체에 접근하는 모든 유저 모드 프로세스는 먼저 객체에 대한 핸들을 오픈 해야 하므로 객체 관리자는 얼마나 많은 유저모드 프로세스가 객체를 사용하고 있는지 쉽게 추적할 수 있다. 추적에는 2단계가 있다.

첫 단계는 존재하는 객체에 대한 오픈 핸들 수로 제어한다. 오픈 할 때 카운터를 증가하고 닫을 때 카운터를 감소하여 0이되면 객체관리자는 자신의 전역 이름공간에서 해당 객체의 이름을 삭제한다. 두 번째 단계는 객체가 더 이상 사용되지 않을 대 객체를 보유하지 않는 것이다.

아래 그림은 사용 중인 두개의 이벤트 객체를 보여준다. 프로세스A는 첫 번째 이벤트를 오픈하고 있으며 프로세스 B는 두 이벤트를 모두 오픈한 상태이다.

커널 모드 구조체는 첫 번째 이벤트를 참조하고 있기 때문에 첫 번째 이벤트의 참조카운트는 3이 된다. 프로세스 A와 B가 자신의 핸들을 닫더라도 첫 번째 객체의 참조 카운트는 1이 되기 때문에 계속 존재 한다.

객체의 오픈 핸들 카운터가 0이 된 이후일지라도 객체의 참조 카운트는 0보다 클 수 있다. 이것은 운영체제에서 여전히 객체를 사용 중임을 나타낸다. 최종적으로 카운트가 0이 될 때 객체 관리자는 메모리에서 삭제 한다.

다음의 경우 시스템이 크래시가 발생 할 수 있다. 객체가 페이지드 또는 넌페이지드에 존재할 수 있다. 디퍼렌스가 디스패치 또는 IRQL 레벨에서 일어나서 이 디레퍼런스로 인해 포인터 카운트가 0이 된다면 페이지드 풀 객체의 메모리를 즉시 해제하려는 시도로 인해 시스템이 크래시 된다.

커널 트랜잭션 관리자(KTM) 객체를 다룰 때에도 지연된 삭제가 필요하다. 특정 드라이버가 락을 소유할 수 있는 상황에서 객체를 삭제하려고 할 때 드라이버는 락을 소유하지 못해 데드락 상황을 유발할 수 있다.

[참고자료]

Windows Internals

강성욱 / http://sqlmvp.kr

객체구조 – 객체 보안

• Windows Server 2008

파일을 오픈 할 때 읽기 용도인지 쓰기 용도인지 지정해야 한다. 읽기 접근 권한으로 오픈 된 파일에 쓰려고 하면 오류가 발생한다. 유사하게 익스큐티브에서 프로세스가 객체를 생성하거나 기존 객체에 대한 핸들을 오픈 할 때 프로세스는 요구 접근 권한의 집합을 지정해야 한다. 이 접근 권한은 모든 객체 유형에 적용되는 표준 접근 권한(읽기와 쓰기, 실행)이나 객체 유형마다 다른 특정 접근 권한을 요청한다.

프로세스가 객체에 대한 핸들을 오픈 할 때 객체 관리자는 프로세스의 요구 접근 권한을 전달하면서 보안 시스템의 커널 모드 부분인 보안 참조 모니터를 호출 한다. 보안 참조 모니터는 프로세스가 요청하는 접근 유형을 허용하는지 객체 보안 디스크립터가 검사한다. 허용한다면 보안 참조 모니터는 프로세스에게 승인된 접근 권한의 집합을 반환하고 객체 관리자는 자신이 생성하는 객체 핸들에 이를 저장한다.

아래 그림은 파일의 접근 권한 대화상자 이다. 설정 부분을 살펴보면 Everyone 그룹은 디렉터리 삭제 접근 권한이 없지만 SYSTEM 계정은 삭제 접근 권한이 있음을 알 수 있다. SYSTEM 특권을 가진 세션 0 서비스가 자신의 객체를 이 디렉터리에 저장하기 때문이다. Everyone은 객체 추가 특권을 갖더라도 세션 0 이외의 세션에서 실행할 때 디렉터리에 객체를 추가하려면 특별한 특권이 필요하다는 사실에 유의하자.

윈도우는 접근 마스크를 지정할 때 추가적인 인자를 줄 수 있는 Ex(확장)버전의API를 지원한다. 오픈 객체 API를 사용하면 오픈 호출 시의 실패를 처리할 때 내재된 레이스 컨디션을 초래할 수도 있다.

이런 종류의 많은 애플리케이션에서 실패가 발생하는 경우는 오픈 API가 생성 API보다 먼저 호출되는 경우다. 이러한 경우 생성동작을 단일 작업으로 할 수 있는 보장된 방법이 없다. 레이스 컨디션과 복잡성으로 인해 오픈 객체 API의 사용이 문제에 대한 해결책이 되지 못하므로 Ex API를 사용해야 한다.

[참고자료]

Windows Internals

강성욱 / http://sqlmvp.kr

객체구조 – 객체 핸들과 프로세스 핸들 테이블

• Windows Server 2008

프로세스는 이름을 사용하여 객체를 생성하거나 오픈 할 때 객체에 대한 자신의 접근을 나타내는 핸들을 받는다. 객체 관리자는 이름 찾기 과정을 생략하고 객체를 직접 찾을 수 있기 때문에 객체 이름보다 객체의 핸들로써 객체를 참조하는 것이 좀더 빠르다.

프로세스는 프로세스 생성 시점에서 핸들을 상속받거나 또는 다른 프로세스로부터 복사된 핸들을 받음으로써 객체에 대한 핸들을 구할 수 있다.

익스큐티브 구성 요소와 디바이스 드라이버는 커널모드에서 실행해 시스템 메모리에 있는 객체 구조체에 접근할 수 있기 때문에 직접 객체에 접근한다.

객체 핸들은 추가적인 이점이 있다.

• 객체 핸들은 자신들이 참조하는 대상을 제외하면 파일 핸들과 이벤트 핸들, 프로세스 핸들 간에 차이점이 없다. (객체를 참조하는 일관적인 인터페이스 제공)
• 객체 관리자는 핸들을 생성하고 핸들이 참조하는 개체를 찾는 데 있어 독점적인 권한을 가진다. (모든 유저 모드 행위를 객체 관리자가 검사할 수 있음을 의미)

객체 핸들은 익스큐티브 프로세스(EPROCESS)블록이 가리키는 프로세스 특정적인 핸들 테이블의 인덱스다. 첫 번째 핸들 인덱스는 4이며 두 번째 8과 같은 방식이다. 프로세스 핸들 테이블은 프로세스가 오픈한 핸들과 관련된 모든 객체에 대한 포인터를 포함한다.

핸들 테이블은 x86 메모리 관리 유닛의 가상-물리 메모리 변환 방식과 유사한 3단계 구조로 구현되며 프로세스당 최대 16,000,000개의 핸들을 제공한다. 프로세스 생성 시에는 최하위 레벨의 핸들 테이블만이 할당되며 나머지 레벨의 핸들 테이블은 필요에 따라 생성된다. 서브 핸들 테이블은 한 페이지에 들어갈 수 있는 엔트리 수에서 1을 뺀 만큼 엔트리로 이루어졌다. 이 한 엔트리는 핸들 감사용으로 사용된다.

아래 그림에서 x86 시스템의 경우 각 핸들 엔트리는 객체에 대한 포인터와 승인된 접근 마스크인 두 개의 32비트 멤버로 이루어 진다. 64비트 시스템인 경우 핸들 테이블 엔트리는 객체 헤더에 대한 64비트 포인터와 32비트 접근 마스크를 갖는 12바이트 크기다.

• Lock : 엔트리가 현재 사용 중인지 나타내는 락 비트 이다.
• Inheritable : 상속을 지정. 이 프로세스에 의해 생성된 프로세스가 이 핸들의 복사본을 자신의 핸들 테이블에 가질 것인지를 나타냄.
• Protect from close : 객체를 닫을 때 감사 메시지를 발생해야 하는지를 나타냄
• Audit on close : 미사용 부분에 위치하는 닫기로부터 보호 비트로서 호출자가 이 핸들을 닫을 수 있게 허용되는지 나타낸다.

시스템 구성 요소와 디바이스 드라이버는 종종 유저모드 애플리케이션이 접근하지 못하는 개체에 대한 핸들을 오픈 할 필요가 있다. 이것은 커널 핸들 테이블내에 핸들을 생성함으로써 가능하다. 이 테이블 내의 핸들은 커널모드라면 어떤 프로세스 컨텍스트에서도 접근 가능하다. 커널모드 함수는 성능에 영향을 주지 않고서 어떤 프로세스 컨텍스트에서든 이 핸들을 참조할 수 있음을 의미한다.

[참고자료]

• Windows Internals
• http://pc.fk0.name/pub/books/windows/insideW2k/html/ch03c.htm

강성욱 / http://sqlmvp.kr

객체구조 – 객체 메소드

• Windows Server 2008

객체 유형이 사용되는 방법에 따라 어떤 객체 유형은 메소드를 명시하는 반면 메소드를 명시하지 않는 객체 유형도 있다.

익스큐티브 구성 요소가 새로운 객체 유형을 생성할 때 하나 이상의 메소드를 객체 관리자에 등록할 수 있다. 이후부터 객체 관리자는 메소드가 등록된 유형의 객체 수명 동안에 잘 정의된 시점(일반적으로 객체가 생성될 때나 어떤 식으로든지 변경될 때)에 메소드를 호출 한다.

다음 표는 객체 메소드와 호출 시점에 대한 내용이다.

이들 객체의 메소드는 일반적인 동작이다. 이 일반화적인 루틴을 완전히 범용화 하기 위해서는 객체 관리자의 설계자가 모든 객체 유형을 예상 해야만 한다. 하지만 객체 유형을 생성하는 루틴은 커널에 의해 익스포트되어 서드파티 구성 요소도 자신만의 객체 유형을 생성할 수 있다.

객체 관리자는 객체 핸들을 생성할 때마다 open 메소드를 호출한다. 즉 객체가 생성되거나 오픈될 때 호출 한다.

Close 메소드를 사용하는 예는 I/O 시스템을 들 수 있다. I/O 관리자가 파일 객체 유형에 대해 Close 메소드를 등록하면 객체 관리자는 파일 객체 핸들을 닫을 때마다 close 메소드를 호출한다. 이때 파일 핸들을 닫는 프로세스가 파일에 사용중인 락을 소유하고 있는지 검사하고 락을 제거한다. 파일 락을 검사하는 작업은 객체 관리자가 직접 할 수 없다.

객체 관리자는 delete 메소드가 등록되어 있다면 메모리에서 임시 객체를 삭제하기 전에 호출 한다. 메모리 관리자는 자신이 섹션을 위해 할당한 내부 데이터 구조체가 해당 섹션 객체가 삭제되기 전에 해제되는지 검증한다. 객체 관리자는 메모리 관리자의 내부 동작에 관해 알지 못하기 때문에 이 작업을 할 수 없다.

Parse 메소드는 객체 관리자로 하여금 자신의 이름 공간 외부에 존재하는 객체를 찾는다면 객체 찾기에 대한 제어를 보조 객체 관리자로 넘기게 한다. 이는 Query name 메소드도 유사하다. 객체 관리자는 객체 이름을 찾을 때 그 경로에서 관련 Parse 메소드를 갖는 객체를 만나면 탐색을 중지한다.

I/O 시스템 역시 사용하는 Security 메소드는 Parse 메소드와 유사하다. 스레드가 파일을 보호하는 보안 정보를 쿼리하거나 변경하고자 할 때마다 Security메소드가 호출 된다.

Okay-to-close 메소드는 시스템 용도로 사용되는 핸들을 악의적(부정확한)닫기로부터 보호하는 추가적인 계층으로 사용 된다. 표준적인 보안 모델하에서 프로세스는 자신의 객체에 대해 완전한 제어권을 가지므로 이들 스레드는 자신의 데스크톱에 대한 핸들을 닫을 수 있다.

[참고자료]

Windows Internals

객체구조 – 형식 객체

• Windows Server 2008

객체 헤더는 모든 객체에 공통적인 데이터를 포함하지만 객체 각 인스턴스마다 다른 값을 가질 수 있다. 예를 들어 각 객체는 고유한 이름을 가지며 고유한 보안 디스크립터를 가질 수 있다. 하지만 객체는 특정 유형의 모든 객체에 대해서는 항상 변하지 않는 값을 가지기도 한다.

어떤 유형의 객체 핸들을 오픈 할 때 접근 권한 집합에서 이 객체 유형에 고유한 권한을 선택할 수 있다. 익스큐티브는 스레드 객체의 경우 여러 접근 권한 중에 종료와 서스펜드 접근 권한을 제공하고 파일 객체의 경우에는 읽기와 쓰기, 추가, 삭제 접근 권한을 제공한다.

객체 관리자는 메모리 절약을 위해 이들 정적이며 객체 유형 특정적인 속성을 새로운 객체 유형을 생성할 때 한번만 저장한다. 객체 관리자는 이 데이터를 기록하기 위해 자신만의 객체와 형식 객체(Type Object)를 사용한다.

객체 추적 디버그 플래그가 설정되어 있다면 형식 객체도 동일한 유형의 모든 객체끼리 서로 연결된다. 이것은 객체 관리자가 필요하다면 이들을 찾고 열거하게 해준다. 이 기능은 생성자 정보 서브헤더를 이용함으로써 가능하다.

객체 관리자는 형식 객체에 대한 서비스를 제공하지 않기 때문에 유저모드에서 형식 객체를 조작할 수 없다. 하지만 형식 객체가 정의하는 일부 속성은 특정 네이티브 서비스와 윈도우 API 루틴을 통해 볼 수 있다.

윈도우 애플리케이션 동기화는 한 상태에서 또 다른 상태로 변화하기를 기다림으로써 스레드가 자신의 실행을 동기화하는 기능이다. 스레드는 익스큐티브 잡, 프로세스, 스레드, 파일, 이벤트, 세마포어, 뮤텍스, 타이머 객체로 동기화 할 수 있다. 그 밖의 다른 익스큐티브 객체는 동기화를 지원하지 않는다.

[참고자료]

Windows Internals

객체구조 – 객체 헤더와 본체

• Windows Server 2008

객체는 객체 헤더와 객체 본체를 가진다. 객체 관리자는 객체 헤더를 제어하고 객체를 소유하는 익스큐티브 구성요소는 자신들이 생성하는 객체 유형의 객체 본체를 제어한다. 각 객체 헤더는 객체의 각 인스턴스에 공통적인 정보를 포함하는 형식객체로 불리는 특별한 객체를 가리킨다. 그리고 옵션으로 4개까지의 서브헤더(이름 정보 헤더, 쿼터 정보 헤더, 핸들정보 헤더, 생성자 정보헤더)가 존재 한다.

객체 관리자는 객체의 유형에 관계 없이 객체를 관리하기 위해 객체 헤더에 저장된 데이터를 사용한다. 다음 표는 객체 헤더 필드 이다.

객체 서브헤더는 객체의 특정 부분에 관한 옵션 정보를 포함한다. 이들 구조체는 객체 헤더의 상단에서부터 여러 오프셋에 위치하며 오프셋의 값은 객체 헤더 내에 저장되어 있다. 이때 생성자 정보의 경우는 예외이다. 이들 오프셋 중에 어떤 값이 0이라면 객체 관리자는 이 오프셋과 관련된 서브헤더가 없다고 가정한다. 생성자 정보의 경우 객체 헤더 플래그 내의 값은 서브헤더가 존재하는지를 결정한다.

쿼터 정보 서브헤더는 객체가 배타적인 객체 플래그로 생성되었다면 이 객체를 접근할 수 있는 배타적인 프로세스에 대한 포인터도 포함할 수 있다. 이 서브헤더는 프로세스에 할당된 쿼터 정보를 포함할 필요는 없다.

각 서브헤더는 옵션이며 특정 조건에서만 존재 한다. 다음의 조건에 대해서 알아보자.

객체 관리자는 새로운 객체가 생성될 때마다 객체 속성으로 불리는 구조체를 통해 마지막 생성 시점이나 특정 동작에 대한 플래그를 전달 받는다. 이 구조체는 객체 이름과 객체가 위치할 루트 객체 디렉터리, 객체의 보안 디스크립터, 객체 속성 플래그를 정의한다.

각 객체는 객체 헤더와 더불어 형식과 내용이 객체 유형에 따라 고유한 객체 본체를 가진다. 동일한 유형의 모든 객체는 동일한 객체 본체 형식을 공유한다. 익스큐티브 구성 요소는 객체 유형을 생성하고 이에 대한 서비스를 제공함으로써 이 유형의 모든 객체 본체에 있는 데이터 조작을 제어할 수 있다.

객체 헤더는 정적이고 잘 알려진 크기를 가지므로 객체 관리자는 객체의 포인터에서 헤더 크기를 뺌으로써 객체의 객체 헤더를 쉽게 찾을 수 있다. 객체 관리자는 서브헤더에 접근하기 위해 객체 헤더의 포인터에서 추가적인 값을 한번 더 뺀다.

표준화된 객체 헤더와 서브헤더 덕택에 객체 관리자는 어떤 객체 헤더에 저장되어 있는 속성이라도 조작할 수 있고 어떤 유형의 객체에도 사용 될 수 있는 소수의 범용 서비스를 제공하면 된다. 이런 범용 객체 서비스가 모든 객체 유형에 지원될지라도 각 객체는 자신만의 생성과 열기, 쿼리 서비스를 가진다.

다음 표는 범용 객체 서비스이다.

[참고자료]

Windows Internals

익스큐티브 객체

• Windows Server 2008

익스큐티브 객체는 일반적으로 사용자 애플리케이션을 위해 환경 서브시스템에 의해 생성되거나 다양한 운영체제 구성 요소의 통상적인 동작으로 인해 생성 된다. 예를 들어 파일을 생성하기 위해 윈도우 애플리케이션은 윈도우 서브시스템 DLL인 Kernel32.dll 에 구현된 윈도우 CreateFile 함수를 호출한다. CreateFile은 일부 유효성 검사와 초기화 이후에 익스큐티브 파일 객체를 생성하기 위해 네이티브 윈도우 서비스 NtCraeteFile을 호출 한다.

윈도우 서브시스템은 자신의 객체 집합(이 중의 많은 객체가 익스큐티브 객체와 직접적으로 대응된다.)을 익스포트 하기 위해 익스큐티브 객체를 사용한다. 예를 들어 윈도우 뮤텍스와 세마포어는 익스큐티브 객체에서 직접 기반을 둔다. 윈도우 서브시스템은 또한 네임드 파이프(named pipe)와 메일 슬롯, 익스큐티브 파일 객체를 기반으로 하는 자원을 제공한다.

POSIX 같은 서브시스템은 객체를 객체로 전혀 지원하지 않는다. POSIX 서브시스템은 POSIX 스타일의 프로세스와 파이프, 자신의 애플리케이션에 대한 그 밖의 자원을 제공하기 위한 기본으로 익스큐티브 객체와 서비스를 사용한다.

다음 표는 익스큐티브가 제공하는 주 객체의 목록이다.

[참고자료]

Windows Internals

커널모드 시스템 디스패칭과 서비스 디스크립터 테이블

• Windows Server 2008

[커널모드 시스템 디스패칭]

커널은 시스템 서비스 디스패치 테이블에서 시스템 서비스 정보를 찾기 위해 시스템 호출 번호를 사용한다. 이 테이블은 각 엔트리가 인터럽트 처리 루틴이 아닌 시스템 서비스에 대한 포인터를 갖고 있다는 점만 제외하면 인터럽트 디스패치 테이블과 유사하다.

시스템 서비스 디스패처인 KiSystemService는 스레드의 유저모드 스택에 있는 호출자의 인자를 스레드의 커널 스택에 복사하고 시스템 서비스를 실행 한다. 이전 모드는 커널이 트랩 핸들러를 실행할 때마다 스레드에 저장하는 값이며 발생할 예외나 트랩 시스템 호출에 대한 특권 레벨을 식별한다.

커널모드 코드는 시스템 호출이 가능하고 CPU는 이미 적당한 특권 레벨 상태이며 커널과 더불어 드라이버도 필요한 함수를 직접 호출 할 수 있다. 익스큐티브 계층의 경우 커널은 자신의 모든 루틴을 접근할 수 있으며 표준 루틴처럼 이들을 호출 할 수 있다. 하지만 외부적으로 드라이버는 이들 시스템 호출이 그 밖의 다른 표준 커널모드 API처럼 익스포트되어 있다면 이들에 접근만 할 수 있다. (실제로 소수의 시스템 호출만이 익스포트되어 있다.)

커널은 NtCreateFile 같은 함수를 직접 호출한다면 커널은 유저모드임을 나타내는 이전 모드 값을 보관하고 전달된 주소가 커널모드 주소임을 탐지해 호출을 실패시키고 유저모드 애플리케이션은 커널모드 포인터를 전달하지 말아야 함을 정화하게 어서트(assert)한다. 하지만 실제로 이렇게 동작하지는 않는다.

익스포트된 API는 실제로 간단한 별칭이거나 Nt버전을 감싸는 래퍼(wrapper)의 기능을 하며 지원되지 않을 수도 있는 인터럽트를 발생하거나 syssenter 대신 이들 API는 가짜 인터럽트 스택을 생성하고 직접 KiSystemService 루틴을 호출 하여 CPU 인터럽트를 그대로 에뮬레이션 한다. 핸들러는 이 호출이 이루어진 실제 특권 레벨을 탐지해 이전 모드를 커널로 설정한다는 점을 제외하면 이 호출이 마치 유저모드로 온 것 같은 동일한 동작을 실행 한다. 이는 호출이 커널로부터 왔음을 알고서 더 이상 실패 시키지 않는다.

각 스레드는 자신의 시스템 서비스 테이블(32비트와 IA64 버전만 해당, 그외 버전은 주소가 하드코딩되어 있음)에 대한 포인터를 가진다. 윈도우는 내장된 두 개의 시스템 서비스 테이블을 가진다. 서드파티 드라이버는 자신의 서비스 호출을 추가하기 위해 이 테이블을 확장할 수 없다.

시스템 서비스 디스패처는 32비트 시스템 서비스 번호에서 2비트 크기의 필드를 테이블 인덱스로 해석해 요청된 서비스가 어느 테이블에 있는 지를 결정한다. 시스템 서비스 번호의 하위 12비트는 테이블 인덱스가 나타내는 테이블에 대한 인덱스 역할을 한다.

[서비스 디스크립터 테이블]

서비스 디스크립터 테이블은 주 디폴트 배열 테이블인 KeServiceDescriptorTable은 Ntosrknl.exe에 구현된 익스큐티브의 핵심 시스템 서비스를 정의한다. 또 하나의 배열 테이블인 KeServiceDescriptorTableShadow는 윈도우 서브시스템의 커널모드 부분에 구현된 윈도우 USER와 GDI 서비스(Win32k.sys)를 포함 한다.

윈도우 익스큐티브 서비스용 시스템 서비스 디스패치 명령은 시스템 라이브러리인 Ntdll.dll에 있다, 서브시스템 DLL은 문서화된 자신의 함수를 구현하기 위해 Ntdll 내의 함수를 호출 한다.

아래 그림에서 보면 윈도우 Kernel32.dll 내의 WriteFile 함수는 Ntdll.dll의 NtWritefile 함수를 호출하고 NtWriteFilie 함수는 NtwriteFile임을 나타내는 시스템 서비스 번호를 전달하면서 시스템 서비스 트랩을 유발하기 위한 적절한 명령을 실행 한다. 이제 시스템 서비스 디스패처는 I/O 요청을 처리하기 위해 실제 NtWriteFile을 호출 한다. 윈도우 USER와 GDI 함수의 경우 시스템 서비스 디스패치는 윈도우 서비스시스템의 커널모드 중 일부로서 로드 가능한 Win32k.sys 내의 함수를 호출 한다.

[참고자료]

Windows Internals