System Compleat.

ArcGISs on 64bit System

Techs
( 정윤진, younjin.jeong@gmail.com  )


사용자 삽입 이미지


작년 겨울 즈음, 친구 해성이가 GIS 용 워크스테이션을 하나 사고 싶다며 사양에 대해 물어봤을 때 뽑아준 견적은 디스크 부분을 제외하면 나름 괜찮았다.
쿼드코어 제온 2개에, 8기가의 메모리, 단일 SAS 디스크.

요런 시스템은 이미 64비트를 염두해 두고 있었지만, 문제는 해성이가 업무에 사용하는 GIS 어플리케이션의 버전이 매우 낮아서 SMP를 지원 하지 않기에, 또 여타의 이유로 64비트에서 구동되기 힘들기에, 64비트 XP는 계륵이었다.  ( 당시 ArcGIS Desktop 9.0, ArcView 3.2 )

일단 설치는 무난하게 마무리 하였으나, 얼마전에 컴퓨터가 자꾸 꺼진다며 고통을 호소하기에 가져와라 해서 이번기회에 아주 그냥 클린업을 해 버렸다.

문제 발생의 원인은 Seagate Barracuda 7000.11 의 1T 디스크였고, 요 디스크를 제거하자 마자 불현듯 다운의 문제는 사라졌다.

다만, OS 의 변경을 생각하고 있었기에, 요새 나돌아 다니는 Windows 7 Beta Build 7100 64bit 를 설치했었는데, 이건 뭐 거의 사용하지 못할 수준이라 언인스톨 해 버리고
Windows Server 2008 64비트를 올렸다. 나름 안정적으로 동작 하길래, 각종 인터넷 뱅킹등의 편의를 위해 Virtual Box 를 올려서 XP 도 하나 더 올리고, 본격적으로 GIS 셋업에 돌입,
위의 사진과 같이 설정이 완료 되었다.

금번 작업에서는, ArcGIS Desktop 9.3 ( ArcInfo ) , ArcView 3.2 를 모두 64비트에 올렸는데, 올리는 과정에서 64비트이기 때문에 애초에 구동 되지 않던 인스톨 프로그램을
Advanced Installer Free 버전을 사용해서 올렸다.

뭐 방법은 나름 간단하지만, 역시 삼십여분간의 삽질은 피할 수 없었고 그게 그렇게 될 수 있다는게 ESRI 의 포럼에서 확인 했기에 내가 이거 못하면 챙피하잖아 해서 끝내버렸쥐.

Advanced Installer를 사용 했던건, XP 32bit 에서 정상 설치된 ArcView 3.2 를 고대로 다시 .msi 파일로 Packing 해 주는데, 이때 레지스트리 정보와 인스톨 시 발생될 수 있는 정보 및 시작 프로그램의 위치를 함께 포함해서 Packing 할 수 있다.

따라서 삽질의 관건은 요 첨보는 프로그램에서 사용하는 Path 규칙을 익혀서 동일한 디렉토리에 위치하도록 만드는 디렉토리 삽질이 하나, 그리고 [ProgramFiles]\[CommonXXX] 에 위치한 .dll 파일 하나 때문에 좀 걸리긴 했지만, 결국 무난하게 동작 했다.


궁극적으로 하고 싶은건, 저런 데이터를 분산시스템에서 한꺼번에 처리하고 거기서 처리된 결과를 클라이언트의 디스플레이에 뿌려주고 싶은건데, GIS에는 워낙 눈이 좀 어두워서 어떤 데이터를 가지고 어떻게 연산을 해야 할지도 잘 모르겠지만, 뭐 또 찾아보면 나오겠지.

암튼 친구 컴퓨터가 무사히 64비트에서 원하는 어플리케이션을 모두 구동 할 수 있어서 잘 되었다.  담번의 인스톨을 위한 것들도 모두 준비되었고.


나중에 튜닝을 좀 더 하자면, I/O 쪽에 약간의 자금을 써서 균형을 맞출 수 있지 않을까 싶다.
스크래치 파일이 많으면 IO 성능은 필수니까-


역시, 모르면 구굴링이 쵝오 -ㅁ-!

-----------------------------------------------------------
최근, ArcView 의 64bit 시스템 설치 관련하여 문의가 종종 있어서, 간략한 설치 과정을 소개합니다.  본 내용은 악의적인 사용자의 ESRI 지적 재산권 침해와는 전혀 관계가 없으며,  여기서 소개하는 내용은 기존에 보유하고 계신 라이센스로 다른 플랫폼에서 사용하기 위한 방법의 소개임을 알려 드립니다. packing 이 완료된 설치본의 유출로 인한 사고 및 설치 중 사용중인 시스템의 파손,손괴 등의 사용자 부주의로 인한 법적 책임은 사용자 본인에게 있습니다.


다음의 방법은 Windows 2008 Server 64bit 및 Windows 7 64bit 에서 모두 정상적으로 잘 동작함을 확인 하였습니다.  별도의 언어팩 또는 GIS 서비스팩 관련한 내용은 다루지 않습니다.

본 내용과 동일하거나 비슷한 설명은 다음의 ESRI 포럼에서 찾아 보실 수 있습니다.
http://forums.esri.com/Thread.asp?c=3&f=38&t=273666

Advanced Installer 라는 Free ware 가 필요합니다.
http://download.cnet.com/Auto-Installer/3000-2084_4-10398642.html

1. VMWare 또는 다른 PC 및 시스템에 Windows XP 32bit 를 준비.
2. 준비된 XP 에 ArcView 를 정상적인 방법으로 설치
3. Advanced Installer 를 XP 에 설치
4. Advanced Installer 를 구동, 다음의 내용과 같이 Packing. 
    -> Program Files 하위의 ArcView 최 상위 디렉토리
    -> Program Files\Common Files\ESRI\mtch.dll
    -> 레지스트리 :  HKEY_LOCAL_MACHINE\SOFTWARE\ 하위의 ESRI  또는 ArcVIEW
5. 생성된 .msi 설치 파일을 Windows 7 64 bit 에서 설치,  이후 Windows XP 에서와 같은
    위치에 파일이 생성되었는지 확인. (레지스트리 포함)  만약 틀리다면, Uninstall 후
    4~5번 과정 반복.
6. ArcView 정상 실행 확인.


위의 세부적인 path 등에 대한 정보는 설치 이후 기간이 지나 기억을 토대로 작성한 것이므로
약간 다를 수 있습니다.  ( 센스로 커버를.. ;; )

이와 관련하여 Windows 7 64bit 에서의 ArcGIS Desktop 및 License Manager 서비스의 기동 등에 대한 이슈가 있으나, 이는 ESRI 에서 잘 안내하고 있으므로 그쪽을 참고하시는게 좋을 듯 합니다.

그럼, 즐거운 GIS 작업 하세요~


( younjin.jeong@gmail.com , 정윤진 )






Drobo, From Data robotics inc.

Techs
( 정윤진,  yjjeong@rsupport.com )

오늘, 웹서핑을 하다가 흥미로운 물건을 발견해서 포스팅 해 본다.
뭐 MAC 진영에서는 소개된지 좀 오래된 물건인것 같은데, 난 첨보니깐.

data robotics 라는 회사의 물건인데, 일종의 외장형 Raid 스토리지로서,
Firewire 800, iSCSI, High-Speed USB 2.0 을 지원 한다.


사용자 삽입 이미지


생긴것도 이쁘장 한 것이, 사무실에도 잘 어울릴 것같고 특히나  본격적인 스토리지는 부담스럽지만 필요한 데이터 용량을 구가해야만 한다면  탁월한 선택이 될 수 있을 듯 싶다.


디스크는 Pro 모델의 경우 8개 까지 장착 가능하며, 일반 모델의 경우 4개 까지 장착이 가능하다.  각 Single volume 은 16T 까지 지원하며, Pro 모델은 16T 볼륨을 16개 까지 생성 가능하지만,  더 큰 사이즈의 단일 디스크가 나오기 까지는 시간이 걸릴 듯 하고.

어떠한 회사던 최소한  컴퓨터로 만들어진 결과물을 보존 및 열람, 실무자들간의 원활한 공유를 위해서는 이러한 형태의 스토리지가 필요한 건 사실이다.  뭐 어떤 개인의 욕구 충족을 위해 어떠한 형태의 영상물을 수집하건간에, 디스크 공간이 모자라서 아까운 자료를 지워야만 하는 경험을 했다면, 이런 장치는 아주 매력적으로 다가 올 수 있을 것이다.  물론 모양도 아주 예쁘니까.

Pro 모델이 아닌 일반 모델은, 팀단위의 파일 공유를 위해 사용 되어 질 수도 있을 듯 하고
특히 CAD 나 3DS Max 같은 그래픽 작업의 결과물, 또는 GIS등의 사용처라던가 아니면 개발회사에서의 소스 Repository 의 용도로 써도 좋겠다. 또는, 최근 가상화 요구에 발맞추어
VirtualBox 용도로 써도 훌륭하겠고.

또 몇몇 네트워크 어플리케이션을 제공 함으로서, iTune 의 Media 서버로 사용한다던가,
쓰기 편한 웹하드의 형태로도 사용 가능하다. 더 나아가 Rsync, Torrent 의 클라이언트로도 사용 가능하여 그 사용 방법이 제법 많아 보인다.

문제는 우리가 알고있는 일반적인 레이드 기술 같지 않아 보이는데, BeyondRaid 라는 기술로
홈페이지에서의 설명은, Single 또는 Dual disk Redundancy 를 지원하고, 확장 가능하며
뭐 기타 본 기술이 짱이라고 말하고 있지만, 역시 써봐야 좋은지 알 것 같다.
지원 하는 파일시스템은  NTFS, FAT32, ext3fs, HFS 를 지원 한단다.  쉽게 말해서
Mac, Linux, Windows 는 지원 한다는 말인데, ZFS 등을 올릴 수 있는지는 뭐 아직 잘 모르겠지만.  누군가의 블로그에서 이걸 써서 VirtualBox 에 OpenSolaris 를 올리고, Drobo의 볼륨을 ZFS 로 사용 가능하도록 삽질 하는게 있는 듯 하다.  난 아직 자세히 보진 않았지만.


역시나 가격이 문젠데, 번들 모델로 구매할 경우 4개 짜리 일반 모델에 1T 디스크 2개 해서
$749 정도다.  Pro 모델의 번들은 조금 더 비싸서, 디스크 구성에 따라 가격은 다르지만
$1550 ~ $3600 정도가지 다양하다.  뭐, 싸지는 않지만 그나마 Storage Enclosure 중에는 제일 싸다고 생각 되는 델의 MD1000 계열 ( Perc 5/e Raid Controller 1개 포함 ) 보다는 싸니까.

I/O 성능이 문제지만, 뭐 언제나 비슷한 RAID 구성에서는 비슷한 성능이 나오게 마련이니까 크게 개의치는 않지만, 심각하게 성능이 딸린다거나 볼륨의 손상이 잦다던가 발열이나 전기를 많이 잡수신다거나 하면 문제가 되겠지.


아무튼, 예쁘고 여러가지 운용 방법도 있는 스토리지라서 귀여워서 좋다.
아, Rack Mountable 제품도 있다.

아직 한국에 진출 한것 같진 않으며, 지리적으로 가장 가까운 리셀러는 일본에 있다.


제품 홈페이지
http://drobo.com

일본 리셀러 페이지
https://mynetjapan.jp/ec/products/list.php?category_id=37

한 1분 슥 훑은 결과 ZFS 삽질처럼 보였던,
Agile Developer, Berlin, Germany  Blog
http://pegolon.wordpress.com/2009/01/13/build-your-own-drobo-replacement-based-on-zfs/


Windows 7 Ultimate 64bit

Techs
( 정윤진, yjjeong@rsupport.com  )

사용자 삽입 이미지

원래 사용하는 노트북이나 데스크탑의 OS 를 자주 재설치 하는 편은 아닌데, 오늘 결혼식도 다녀오고 뉴스도 그렇고 기분도 꾸리꾸리 해서 Windows 7 을 설치해 보았다.

노트북 선정 최우선 기준이 항상 무게이기 때문에, 현재 사용중인 Lenovo X61 을 선택하게 되었는데 몇몇 드라이버를 제외하면 수월하게 설치 되었다는 느낌이다.

다만, IE8 이 기본 설치인데 이게 오류가 참 많다.  쩍하면 '오류를 무시할래 껐다켤래' 식의 메세지가 나오고, 간혹 OS 자체가 운명하시기도 하다가, 급기야 VirtualBox 같은게 동작하지 않기도 하는등, 조만간 재설치의 귀찮음을 감내 해야만 하는 OS 라는 사실을 깨닫고 있는 중이다.

회사의 AJ 는 요새 안드로이드 열폭 중이던데, 나는 너무 쓸데 없는데 시간을 보낸 것 같기도 하지만, 뭐 아무튼 Windows 3.1 디스켓 13장 짜리일 때부터 발전을 거듭해온 시작 화면의 로고는 '새 윈도우 설치했다' 라는 느낌을 충분히 주고 있어서 귀찮아도 그냥 쓸까 싶다.


이제 막 설치해서 별로 알아본건 없고, 새로운걸 알아내게 되면 뭔가 또 써 봐야겠다.

훗,  설익은 총각의 밤이란-

스토리지, 파일 시스템, 그리고 가상화.

Techs
( 정윤진, yjjeong@rsupport.com )


일을 하다 보면, 스토리지에 관련된 이슈가 참 많이 생긴다.  NT 계열이건 Unix 계열이건, 스토리지에 대해서는 뭐 일반적인 스토리지는 많이들 구성하니까 Raid 의 종류별 성능이라던가 이런거는 뭐 너무도 일반화 되어 있어서, 별로 기술이라는 생각도 잘 들지 않게 되고.

파일시스템도 마찬가지여서, 리눅스의 ext2 시절부터 골때렸던 여러가지 이슈들 부터 메인 개발자가 사고쳐서 감방간 ReiserFS, 요새의 Solaris 기반의 ZFS 등 운영체제에 따른 OS 선택 옵션도 참 많다.

또 요새는 글로벌하게 분산되는 파일 시스템도 많아서, 뭐 사실 안정성이 문제긴 하지만 일종의 Torrent 같은 구현을 파일 시스템 레벨에서 구현하는 것도 종종 있기도 하고.

문제는 어떤 서비스에 뭘 선택해서 사용하느냐인데, 단일 시스템에서 대량의 ( Peta 규모 ) 파일시스템을 Aceess 할 일은 거의 없다고 본다. SAN 이나 iSCSI 로 엮어 NetApp이나 EMC의 스토리지와 연결하고, 이 볼륨들은 서버에서 원하는 형태로 스케일링 하여 파일시스템으로 마운트 되면서, 필요에 따라 NFS 나 CIFS 로 동일 용도의 서버로 묶는다든지, 아니면 오라클이나 DB2 등의 데이터베이스 시스템에 맞게 튜닝하여 RAC 나 클러스터링 구성을 한다 든지.

VMWare 의 ESX 서버를 SAN 에 붙여 사용하면 요거는 활용 가능성이 더욱 넓어진다.
최근 대세인 Cloud Computing 을 어떻게 구성하느냐에 따른 방법론은 참 많고, Amazon 의 EC2 관련 서비스를 어떻게 구현할 수 있을까 라는 것도 많겠지만, 궁극적으로 성능 - 백업 - 배포 - 관리 등을 동시에 고려한다면 어지간한 대규모 프로젝트보다 많은 노력이 필요하겠지.

쓰다보니 두서도 없고, 주제도 별로 제목과 맞지는 않지만 뭘 어떻게 하자는 것도 아니고
사실 고민 스러운 일도 아니다.

이전에도 한번 소개 했었지만, 간단한 파일시스템의 가상화를 통한 대량의 파일 복구 또는 DB 복구를 위해서 종종 사용하는 방법인데,  시스템에서 즉석으로 원하는 파일 시스템을 만들고
이를 마운트해서 원하는 성능을 얻는 방법. 뭐, 리눅스 용이고 간단한 dd 커맨드로 가능하다.
물론 해당 파일 시스템을 사용하기 위한 커널 모듈 또는 툴 등이 필요한것은 지당하다.

dd if=/dev/zero of=test_hoho.img bs=1k count=10000  ( 원하는 블럭사이즈의 원하는 파일 시스템 크기 )
mkfs.reiserfs test_hoho.img
mount test_hoho.img /mnt/test

ext3 의 dir_index 를 붙이기전, ( 뭐 일종의 파일시스템에 대한 b-tree indexing 정도로 이해하고 있다 ) 현저하게 떨어지는 대량의 파일에 대한 컨트롤 능력에 필요할때의 응급조치 랄까.

어느 순간에 대한 백업으로서 써도 좋다. 아니면 이렇게 만든 파일 시스템에 OS 를 올려서 배포를 해도 좋겠지.  분산컴퓨팅에 많이 쓰기도 하고.  나중에 pxe boot 와 연계해서 올리는 방법에 대해 간단히 설명하게 되면 하기로 하고.

systemimager 와 같은 유틸리티로 Cloud computing 을 구성할 수도 있고 뭐, 널린게 방법이니까.


어쨌든, 이 주제없고 웬지 Storage Tab 이 썰렁해 보여 아무렇게나 써제끼는 글에 대한 결론아닌 결론이라면, 역시 돈있으면 NetApp, EMC, 돈없으면 HDFS GFS ZFS 라는 거다.
서버 - Filesystem 이 분리 될 수 있는 NFS 구조라면,  NFS 자체는 OpenSolaris 의 nexenta 같은 OS를 사용하고, 이를 윈도우에서 마운트 하던 유닉스에서 마운트하던 맘대로 사용하면 되시겠다.

고가의 Veritas Cluster 나 Suncluster, Oracle RAC 같은 구성이라면, 돈있으면 SAN 돈없으면 iSCSI 겠지.  이럴때도 iSCSI 를 사용하기로 했다면, nexenta 가 훌륭한 답이 될 수도 있다.

암튼, 이런저런 두서없는 끄적거림에 대한 나만의 결론은, 돈이 있건 없건 대량의 사이즈에 대한 백업 또는 스냅샷 정책이 있어야 하고, 파일시스템 레벨에서의 정합성 및 장애 극복에 대해 항상 염두해 두어야 회사에서 잘리는 일이 없지 않을까?


그냥 썼다.  비도 오고 기분도 그렇고 해서~

Global, 혹은 Cache 에 대한 시스템적 고민

Techs
( 정윤진, yjjeong@rsupport.com )

간혹 그런 생각이든다.
'과연 시스템적으로 단순한 웹 서비스 구조에서 글로벌을 감안 할때, 메인 시스템 인프라와 같은 규모의 시스템이 지역적으로 필요 할 것인가'

이에 대한 답은 서비스의 동작에 따라 다르겠지만, 단순 컨텐츠의 경우 CDN 등을 이용하는 숱하고 숱한 방법들은 이미 많다.
하지만, 정적 컨텐츠 이외의 동적 컨텐츠가 많은 지역별 거점을 중심으로 운용되는 서비스의 경우에 시장성이 불투명하지만 일부 고객을 위해 서비스를 지속해야 하는경우, 제일 고민 되는 부분은 역시 시스템 및 관리를 위한 비용, 소위 말하는 TCO 가 관건이 되지 않을까.

미국에 메인 센터가 있고, 유럽에 일부 고객이 발생되기 시작한 시점에 사업 규모로서는 유럽에 미국만큼 큰 센터를 두는게 맞겠지만, 아직 얼마만큼의 고객이 확보 될지 모르는 지역에 대규모의 인프라 비용을 투자하는건 아무래도 리스크가 따르기 마련이다.

이런 경우의 해법이 무엇일까 하는 부분은 서비스의 유형별로 많이 다르겠지만, 일반적 웹 서비스에서 이런 질문은 이렇게 치환 될 수 있을 것이다.
'네트웍 회선 품질이 현저한 지역에 고품질의 서비스가 필요한 경우, 어떻게 해결 할 수 있을까?'

파일 전송을 주로 하는 서비스라면 CDN 과 같은 글로벌 업체를 통하는 방법외에는 답을 찾기 쉽지 않다. 하지만 채팅이나, image 서버를 별도로 구성한 웹 서비스의 경우, css 나 js, html 등의 몇 kb 전송에도 수초가 걸리는 상황이라면,  답은 Proxy 에서 찾을 수 있지 않을까.

웹 - WAS - DB 의 경우에는, GeoIP 를 사용할 수 있는 DNS 또는 웹 서버를 사용하여 웹 서버 자체를 글로벌하게 운용하여 답을 찾을 수도 있다.  또는, 웹 서버 자체가 많이 무겁다면, 효율적으로 Cache 를 수행하는 NginX 나 Varnish 등을 통해 적절한 프락싱을 통해 비슷한 해답을 얻을 수도 있을 것이다.

앞에서의 예와 같이, 미국에 수억의 시스템이 있다.  이를 일본과 유럽에 서비스 하고 싶다면, 일본과 미국에 저렴한 서버 호스팅 또는 , 가능한 경우 Amazon 의 EC2 와 같은 서비스에 서버를 한대 둔다.  여기에 NginX 나 Varnish 를 올리고, 필요한 경우 memcached 등과 같은 로직에 녹여 낼 수 있는 캐슁 툴 및 opcode 레벨의 cache 를 지원하는 각종 자원을 사용하거나, 아니면 아주 단순하게 squid 등의 오래된 고전적인 proxy를 통하여, OS 또는 시스템의 자체 Cache 를 믿고 서비스 하는 방법- 


뭐, 이미 이러한 방법을 수행하고 있는 업체도 많겠지만 중요한건 저렴한 비용으로 어느정도 동적인 컨텐츠에 대한 지역별 분산을 노릴 수 있는 잇점이 있다. 

아직 테스트 해 보진 않았지만, 일본에서 네이버와 같은 ( 네이버는 URL 구조가 좀 복잡하지만 ) 웹 서비스에 대해 squid 만 돌려 보아도 그 효과는 순식간에 나타난다.
뭐, 일부 사람들은 CDN 과 같은거 아니냐  라고 할 수 도 있지만, 틀린말은 아니다.
다만 CDN 을 운용하면서 발생 하는 비용이  직접 서버를 간단하게 구성해서 운용하는 비용보다 저렴 하지는 않을 것으로 생각된다.

똑같은 요청을 반복해서 처리 ( 단순 Static 한 컨텐츠가 아닌, 일부 동적인 자원에 대해서도 장기적으로는 동일한 요청에 대한 응답이므로 ) 하는 정도로 시장성이 충분 해 질 때 까지 지역적 서비스를 선별적으로 빠르게 할 수 있다면, ( 물론 로그인과 같은 DB Connect 가 발생하는 액션은 여전히 느리겠지만 ) Comet 이나 간단한 채팅,  css 또는 html, php 와 같은 자원에 대해서는 환상적인 현지 고객의 만족을 얻어 낼 수 있을 것이다.


역시, 오픈소스는 조합하기 나름인가 보다.