728x90
 
 
 

728x90
728x90
윈도우 모바일 6 부터 기본적으로 SQL Server 2005 Compact Edition (이하 SQL CE)가 기본적으로 OS 이미지에 올라가 있습니다. 배포하는 과정 없이 쉽게 사용할 수 있다보니 이전보다 개발자들이 SQL CE를 자주 쓰는 듯한 요즈음입니다. 하지만 몇가지 이유들로 인하여 데이터 엑세스시에 Not Enough Storage 에러를 발생하는 경우가 있는 것 같습니다.

윈도우 모바일 6 의 DLL 메모리 적재 방식

모든 문제점들의 원인이라고 단정지을 수는 없지만 기본적으로 윈도우 모바일 6가 DLL을 메모리에 적재하는 방식에 대하여 한번 집고 넘어갈 필요가 있습니다. SQL CE 팀블로그에 올라온 포스팅(http://blogs.msdn.com/sqlservercompact/archive/2007/10/26/troubleshooting-can-t-load-sqlce-dll.aspx) 에서 해당 내용을 발췌해 봤습니다.

When a DLL is loaded in one process, Windows CE reserves that address space in every process address space. Multiple processes that use the same DLL share it at the same relative address in every process. If your application does not use the same DLL, it cannot use the memory that is reserved for that DLL. In other words, Windows CE does not map a RAM-based DLL at an address where another process maps another DLL. For example, if Process A loads DLL X at address 0x00970000, Windows CE does not map DLL Y in the Process B address space at 0x00970000. Instead, Windows CE seeks the next lower address that is available, depending on the size of DLL Y. So if DLL Y is in the size range of 128 KB, Windows CE selects 0x00950000 if that address is available for Process B. Because of the way that Windows CE allows processes to share a common DLL, Windows CE does not permit two different processes to load two different DLLs at the same relative address of each process.

당연할 이야기일지 모르지만 서로 다른 DLL 에게 동일한 메모리 어드레스를 할당하지 않는 다는게 요입니다. 당연한 이야기도 한정된 메모리 영역을 가지고 있는 스마트 디바이스로 넘어오면 치명적인 문제가 될 수 있습니다. 여러개의 분산된 DLL 을 동적으로 로딩하는 어플리케이션이 있다고 가정하면, 모든 DLL 들은 자신의 용량과 관계없이 최소한의 메모리 이격을 둔채 (본문에서 128KB) 메모리를 할당받게 될 것입니다. 이는 곳, 메모리 영역이 금방 소진될 수 있다는 의미가 됩니다.

닷넷 컴팩트 프레임워크와 메모리 적재 방식의 상관관계

컴팩트 프레임워크를 포함한 모든 닷넷 프레임워크는 관리코드 (Managed) 사용시에 자동으로 GC (Garbage Collector)가 사용하지 않는 메모리 영역의 객체 인스턴스를 해제하고 자원을 해제시킵니다. 그런데 컴팩트 프레임워크에서 사용되는 SQL CE 관련 객체들에 자원 해제와 관련한 내부적인 문제가 있는 것으로 보입니다.  (참고 : http://support.microsoft.com/kb/824462, SqlCeCommand objects are not automatically disposed if you use a SqlCeDataAdapter object)

If you use the SqlCeDataAdapter object to populate a DataSet object, and you do not explicitly call the Dispose method for all the associated SqlCeCommand instances, you may receive the following error message:
Error Code: 8007000E
Message: Not enough storage is available to complete this operation.
Note The type of SqlCeCommand instances may be select, insert, update, or delete.

쿼리문 할당을 위해 사용한 SqlCeAdapter.SelectCommand, SqlCeAdapter.InsertCommand, SqlCeAdapter.UpdateCommand, SqlCeAdapter.DeleteCommand 객체가 할당된 SqlCeCommand 객체를 명시적으로 소멸(Dispose) 시켜줄 것을 권고 하고 있습니다. 추측컨데, 데이터 Row가 많은 자료의 경우 데이터를 Insert 하면서 객체를 소멸시키지 않고 반복적으로 루프문에서 사용할 가능성이 높은데 이 과정에서 메모리에 계속 새로운 영역들이 Reserve 되는 것이 아닌가 싶습니다.

다만 의아한 것은 이러한 에러가 발생한 시점에 메모리 용량을 점검해보면 수십메가 이상이 남아있는 경우가 많습니다. 이는 아마도 실제 메모리가 소모되어 발생했다기 보다 메모리 주소를 더이상 Reserve 할 수 없어서 발생하는 것이지 싶습니다.

참고자료

- INFO: Understanding Windows CE DLL Load Failures (http://support.microsoft.com/kb/326163)
- Methods to dispose of SQL Server CE, SQL Server 2005 Compact Edition, or SQL Server 2005 Mobile Edition managed objects from memory (링크)
- SQL Mobile 2005 - Error : Not Enough Storage is Available (링크)
728x90
728x90

터미널 서버의 설치를 마치고 서버를 재부팅 하고 나면 잠시 변경된 내용이 적용되고 다시 서버 환경으로 로그인을 할 수 있다. 서버 관리자를 실행하고 설치한 터미널 서버 역할이 잘 정의가 되었는지 확인해 볼 수 있다. 이전에 항목이 0개였던 역할 노드에 터미널 서버가 추가된 것을 확인할 수 있고 우측의 Detail 팬에서도 해당 내용을 같이 확인할 수 있다.

그런데 왼쪽의 노드 트리를 유심히 보면 처음 보는 용어가 위치해 있는 것을 알 수 있는데, 이름하여 "TS RemoteApp"이다. TS RemoteApp 은 윈도우 서버 2008 에서 터미널 서버가 갖고 있는 기본 기능이다. Citrix의 Presentation 서버 (MetaFrame) 를 들어본 적이 있다면 익숙할 Seamless 환경을 지원하던 Presentation 서버의 Publish 기능을 알고 있을 것이다. 퍼블리싱 된 소프트웨어는 사용자 클라이언트 PC 에서 마치 로컬 실행되는 어플리케이션처럼 구동되는 모습에 많이들 감탄했을 것이다.

TS RemoteApp 은 Citrix와 같은 솔루션의 도움 없이 윈도우 서버 2008과 터미널 서버 역할 만으로 이러한 기능을 제공해 준다. 강력한 컴퓨팅 파워를 필요로 하는 어플리케이션이나 공통 어플리케이션을 서버에 설치하고 RemoteApp 으로 제공하면 일종의 SaaS (Software as a service) 개념이 가미된 사용자 컴퓨팅 환경을 구성할 수 있게 된 것이다.

RemoteApp 프로그램 추가

서버 관리자에서 터미널 서버 노드를 선택하면 제일 오른쪽에 위치한 작업팬에 사용자가 할 수 있는 몇가지 액션에 대한 기능들이 보인다. 그 중 맨위에 위치한 "RemoteApp 프로그램 추가" 기능을 통해서 서버에 설치된 프로그램을 터미널 서버 RemoteApp 으로 사용자들에게 제공할 수 있도록 설정할 수 있다. 프로그램을 추가하기 전에 배포할 어플리케이션이 서버에 설치가 되었는지 확인하도록 하자.

기능을 실행하면 무척 간단한 마법사가 어플리케이션 배포를 도와준다. 특별한 설정이 필요 없다면 무조건 "다음"만 선택해도 되지만 처음 RemoteApp 으로 어플리케이션을 배포한다면 어떤 설정들을 할 수 있는지 간단하게 살펴보는 것도 좋다.

마법사의 두번째 화면은 정상적인(?) 방법으로 설치되어 윈도우의 프로그램 관리자가 설치 / 제거를 지원할 수 있는 모든 어플리케이션이 목록에 출력된다. 만약 특별한 설치과정이 제공되지 않고 Stand-Alone 으로 설치된 프로그램을 배포하고자 한다면 "찾아보기" 기능을 이용해서 직접 실행파일을 배포해도 상관없다. 이쯤에서 아이디어가 떠오른 사람도 있겠지만, PDF 와 같은 문서파일을 RemoteApp 으로 배포하는 것도 물론 가능하다. 정책이라던가 일정 처럼 공유되어야만 하는 정보를 넘길수도 있을 것이다.

마법사를 통한  간단한 설치 절차가 끝나고 나면 중앙의 팬 하단에 RemoteApp 프로그램 목록에 설정한 프로그램이 등록된다. 등록한 이름과 경로, TS 웹 액세스, 인수 등의 항목이 보이는데 TS 웹 액세스에 관해서는 다음 아티클에서 상세히 설명하도록 하겠다.

등록된 어플리케이션 목록에서 마우스 오른쪽 버튼을 누르면 RemoteApp 프로그램에 대하여 관리자가 할 수 있는 작업 목록이 팝업된다. 등록된 어플리케이션을 사용자들이 액세스 할 수 있도록 하기 위한 방법은 여러가지가 있는데 다음 아티클에서 소개할 TS 웹 액세스가 가장 진보된 형태의 배포 및 액세스 방법이다. 아직 웹 액세스는 설치하지 않았으므로 RDP 파일과 MSI 파일로 배포하는 방법을 볼 까 한다.

RDP 파일은 일반적으로 터미널 서버 액세스를 위해 RDP 설정 파일을 만들어 주는 것과 동일하다. MSI 파일형태로 만들게 되면 사용자 PC 에 프로그램을 설치하는 것과 동일한 (즉, 프로그램 추가 제거에서 RemoteApp 어플리케이션을 제거할 수 있는 형태) 방식으로 설치가 된다. 다만, 이 두가지 방법의 단점은 사용자에게 RDP 파일 혹은 MSI 파일을 배포해야 하기 때문에 1) 공유폴더를 통한 배포, 혹은 2) 액티브 디렉토리 정책을 통한 배포를 해야만 한다. 테스트 환경은 AD가 설치되어 있지 않아 공유폴더를 통해서 MSI 파일을 배포해 보았다.

 

배포된 MSI 파일을 설치하고 나면 사용자의 클라이언트 PC 에 "원격 프로그램" 이라는 프로그램 그룹이 생성되고 그 하단에 배포되는 모든 RemoteApp 프로그램이 설치된 모습이 보인다. 물론, 마법사를 통해 MSI 패키징을 하는 과정에 다른 경로나 이름을 지정했다면 그 설치 위치는 달라졌을 것이다. RDP 파일을 배포하는 경우는 이러한 절차나 모습없이 RDP 파일을 직접 더블클릭해서 RemoteApp 을 구동시키게 된다.

설치된 RemoteApp 구글 어스를 실행하면 위의 사진처럼 마치 로컬 어플리케이션이 실행되는 것과 같은 모습을 보여준다. Seamless 방식으로 어플리케이션이 구동되고 있기 때문이며 사용자의 높은 데스크탑 사용자 경험을 느낄 수 있는 방식이다. RemoteApp 은 Citrix의 Presentation 서버가 제공하는 다양한 기능 (예>로드밸런싱, 어플리케이션 격리화 환경 등) 을 제공하지는 않지만 중소규모의 엔터프라이즈 환경에서라면 얼마든지 다양한 아이디어를 통해서 업무에 응용해서 사용할만한 매력적인 기능임에는 틀림이 없다.

- NoPD -

728x90
728x90

* 본 문서는 마이크로소프트 가상화 웹사이트에 게시된 "Flexible Desktop Computing 백서"를 번역 및 의역한 글입니다. 번역 내용 중 잘못된 부분이나 문제가 될만한 부분은 지적해 주시면 수정하도록 하겠습니다.

사용자 삽입 이미지
지금까지 특정한 사용 환경에서 요구되는 다양한 니즈를 만족시키기 위해 마이크로소프트가 제공하는 다양한 클라이언트 컴퓨팅 옵션에 대하여 알아보았다. 이에 따르면, 주어진 사용자 시나리오의 요청을 감안하여 적절한 컴퓨팅 옵션을 선택할 필요가 있다는 것을 우리는 알수 있었다. 이번 포스팅에서는 정형화된 사용자 프로파일이나 개인에 따라 어떤 컴퓨팅 옵션을 선택할 수 있는지에 대하여 알아보도록 하겠다.

이릉 위해서 이번 포스팅은 여러 정형화된 사용자 시나리오를 4가지 영역으로 나누어 알아보겠다 : 1. 모바일 정보 사용자, 2. 오피스 정보 사용자, 3. 파워 유저, 4. 현업 사용자. 이러한 사용자들이 모든 기업의 여건을 나타내 주는 것은 아니므로 컴퓨팅 옵션을 선택하는 좋은 예로써 참고하는 것이 좋을 것 같다. 각각의 사용자를 간단하게 적어보면

1. 모바일 정보 사용자

이 부류의 사용자들은 출장이나 외근이 잦은 사용자 층이다. 사용자들은 로컬에서 구동되는 다양한 어플리케이션(예>오피스, CRM, ...)을 사용하며 오프라인 상태에서도 어플리케이션과 데이터를 엑세스 할 수 있어야 한다. 영업사원이나 기업의 임원들이 이러한 사용자의 대표적인 예이다.

2. 오피스 정보 사용자

이 부류의 사용자들은 업무시간의 대부분을 네트웍에 연결된 상태에서 보내고 자신에게 주어진 다양한 업무를 처리할 수 있는 리치 클라이언트를 사용하는 계층이다. 이들은 오피스, CRM, ERP 등의 어플리케이션을 주로 사용하며 웹이나 프로젝트 관리 도구등도 사용한다. 때에 따라서 사용자들은 집에서 그들의 회사 데스크탑에 연결하거나 현업 어플리케이션을 사용하고 싶어한다. 전형적인 사무실 근무자가 이 계층에 속한다.

3. 파워 유저

파워 유저는 회사 네트워크 안에서 높은 수준의 특화된 현업 어플리케이션을 사용한다. 이들에게는 신뢰성 있는 엑세스를 제공하는 고성능, 고가용성 컴퓨팅 솔루션이 필요하다. 많은 파워 유저들은 종종 한곳에서만 작업하는게 아니라 사무실 여기 저기에서 작업할 수 있는 환경을 원하기 때문에 "자유석(Free Seating)" 환경이 필요하다. 재무 관계자나 CAD 디자이너, 그래픽 디자이너들이 파워 유저 계층에 속한다.

4. 현업 사용자

현업 사용자는 데이터 입력 작업이 주된 업무이다. 이들은 몇 안되는 현업 어플리케이션을 사용하고 회사의 네트워크 범위 안에서 업무를 본다. 일반적으로 고성능의 컴퓨팅 파워가 필요하지 않지만 파워 유저와 마찬가지로 사무실 여기저기를 옮겨 다니면서 일을 하는 계층이다. 콜센터 에이전트 라던가 은행 창구 직원, 공장 근로자, 캐시어등이 현업 사용자를 대표하는 예이다.

각각의 사용자 계층은 특화된 컴퓨팅 파워 혹은 컴퓨팅 환경을 요구하고 있다. 다음 포스팅에서는 이러한 다양한 사용자들의 니즈를 만족시켜 주기 위하여 IT 조직이 할 수 있는 내용들을 앞서 포스팅한 Flexible Desktop Computing 기술들과 매핑하면서 어떠한 기술을 어떠한 사용자층에게 제공해야 하는지 알아보도록 하겠다.

- NoPD -

728x90

+ Recent posts