정말 오랫만에 블로깅을 하는 거 같다...ㅡㅜ 그간 정신이 없었으나... 하지만 몇 번의 진행 케이스를 통해서 Windows에 대해 더욱 알게 된거 같아 기쁘기 그지 없다...ㅋ (하지만 해당 내용은 블로그 및 기타 사항을 통해 절대 외부에 유출하면 안된다...ㅡㅜ)
본 내용은 모두 Microsoft Windows internals 에 수록되어 있음을 밝혀 둔다!
Smss 이놈 이름은 세션 메니저다. 그렇다면 세션이 뭐냐? 솔직히 나도 모른다... ㅋㅋㅋ 그저 app 나 서비스가 돌아가기 위한 베이스라는 것 밖에는...
하지만 이 세션이라는 놈이 각 터미널 세션마다 하나씩 생기지는 않는다는 점!!! 그저 해당 새로운 세션 요청이 들어오면 처리 하기 위한 스레드만 생성해 놓고 있다. 아래 그림에서 보는 것 처럼 세션은 3개 지만 smss.exe 프로세스는 하나다. (Tei 노래가 생각나는군... "사랑은 하나다")
왜 이름이 세션 메니저가 됐는지는 모르겠다. 하긴 처음에 Windows 를 설계할 때는 콘솔 세션만 생각했을 태니... 그리 됐는지도...
이놈의 가장 중요한 역활은 "내가 젤루 먼저 실행" 이다. 이놈은 특이하게도 Windows API를 사용하지 않는다... 왜? 젤먼저 실행 되니깐! 왜 젤 먼저 실행 되면 Windows API를 실행을 못할까? Windows 서브 시스템이 아직 로딩 되지 않았기 때문이다.!!!
SMSS는 이제 시스템이 OS의 구성 요소 중 하나로 볼 수 있다. 자 이놈의 중요한 역활은 세션을 준비하는 것이다. 자 그럴려면 Windows 서브시스템인 csrss.exe를 실행 하고 Win32k.sys 커널 부분을 로드하게 될것이다. 앞으로 Win32 API를 쓰기 위해서는 당연히 여러 DLL도 로딩하게 될것이다. 이젠 맨땅에 해딩 (Windows native 함수 이용)을 하지 않아도 된다...! 고맙다... Thx~ 그리고 또 뭘할까? 레지스트리...!!! 아 지겹고 짜증나는 구조 레지스트리...ㅡㅜ 이놈의 초기화를 완료 한다. 레지스트리?? 이녀석들 다 파일이다. SMSS가 관리하는 hive 위치만 알면 ㅋㅋㅋ 레지스트리의 위치는 쉽게 파악이 가능하다. HKLM\SYSTEM\Current-ControlSet\Control\hivelist key
뭐 그밖에 마지막으론 로그인 하기 위한 초기 과정으로 winlogone.exe를 실행한다.
마지막으로 Windows 2008에서는 CSRSS.exe 가 SMSS의 하위 프로세스로 구현되진 않은것 같다. 아무튼 호출하는건 맞는데... 실제 부팅 프로세스가 끝나면 해당 프로세스는 종료가 되는 건가? 아니면... 아까 내가 디버가 열어서 smss.exe 디버깅 하는 바람에 종료 됬나? ...;;; 아까 내가 디버거로 본 녀석은 smss.exe가 아니였던가... 아무튼 갑자기 미궁으로 빠졌다...ㅡㅜ
아 역시... Windows 2008...^^v 그 전에 바이러스로 인해 고생했던 경험 때문인지 SMSS.exe 가 상주 프로세스로 구현되진 않았다는 것을 확인했다.
MSCS 구성 시에는 Domain Controller 와 클러스터 노드 간의 분리를 통해 시스템의 안정성과 성능을 높이시기 바랍니다.
Domain Controller와 클러스터 노드의 통합 시 발생 가능한 사항
1. Domain Controller 역할 노드 장애 후 서비스 시작 시 클러스터 서비스가 시작되지 않음 클러스터 및 기타 서비스들의 시작 시 도메인 계정을 통해 인정을 받아야 합니다. 하지만 해당 시점에 Domain Controller 역할 노드에 문제가 있을 경우 인증을 받지 못해 해당 서비스가 시작 되지 않을 수 있습니다.
2. Disk 접근 시 성능 이슈가 발생 할 수 있음 Domain Controller 의 경우 ntds.dit 파일에 대한 크래쉬 방지를 위해 Write Cache가 Disable 되어 있습니다. 즉 대량의 데이터 I/O가 발생할 경우 성능 저하의 경험으로 이어질 수 있습니다.
Domain Controller와 클러스터 노드의 단일 머신 설치의 경우 일반 환경에서 가장 흔히 볼 수 있는 구성입니다. 그럼에도 불구하고 분리를 권장 합니다.