이 글은
“오픈소스 개발자들이여! 메인프레임을 주목하라”
( http://www.bloter.net/archives/28563 )
트랙백을 위해 작성된 글 입니다.
감사합니다.
=======================================================================================
2003년 제가 경험했던 Mainframe zlinux 의 실패...
당시는 z990 머신에 z/VM을 올리고 SLES (SUSE Linux Enterprise Server) 를 올렸었는데
정말 색다른 경험이었습니다.
빵빵한 메인프레임 머신에 linux라니.. 그런 경험을 해 보는 것만으로도 많은 이의 부러움을 샀었죠...

SAP, UDB로 통합경영정보 시스템을 구축해서 사내에서 공로상을 수상하기도 했었는데 감회가 새롭네요...
당시 IBM 박재화 부장님의 도움도 많이 받았었습니다.
그러나 해당 시스템을 12개월 정도 밖에 사용하지 못 하고
특정 Blade 서버 Architecture로 전환을 했습니다.
그럼 왜 그런 실패 경험 했었을까요?
정리해 보면 아래와 같습니다.
1. TCO 문제
당시 IBM 메인프레임은 H/W 유지보수 비용이 굉장히 많이 들었습니다.
물론 지금도 그러겠죠?
그리고z/VM 사용료도 만만치 않았었습니다.
게다가 당시는 linux 배포판이 SLES 밖에 안 되는데
zlinux용 SLES 가격도 매우 비쌌었습니다.
결국 도입 초기 산정했던 TCO 계산에 문제가 있었던 것이고
IBM과 불편한 유지보수 계약 문제가 걸림돌이 되어서
결국 zlinux를 포기할 수 밖에 없었습니다.
2. S/W License 문제
당시는 Oracle 과 Weblogic 을 zlinux 위에 올리는 것을 표준 아키텍쳐로 검토 하고 있었습니다.
Oracle은 zlinux 기준이 아니라 z/VM의 CPU당(정확히는 IFL당) 견적을 받는 것으로
global license 정책 표준이 있었음에도 불구하고
한국 Oracle에서는 zlinux 당 (Guest OS별) license를 산정하는 정책을 적용 해야 한다고 했었습니다.
BEA (당시 Weblogic제품 회사) 에서는 해당 라이센스 정책이 없어서
zlinux에 올라가는 Weblogic은 CPU가 1EA라도
더 비싸게 받아야 한다고 BEA 파트너 업체가 터무니 없는 가격을 줬었습니다.
각종 상용 Application 들의 준비되지 않은 라이센스 정책과
터무니 없이 비싼 가격 때문에 문제가 많았습니다.
3. 성능 문제
민감한 문제이기에 언급하기 쉽지 않오나 당시 상황을 간단하게 정리하면 아래와 같습니다.
CPU, Memory Over-Commit이 제대로 동작하지 않았습니다.
예를 들어 이론상으로 z/VM에 할당된 Memory 가 2GB라도
여러 개의 Guest OS(각 linux) 들이 할당받아 사용하는 메모리의 총합이
2GB 이상이 될 수 있어야 하는데 그러지 못 했습니다.
CPU 파워도 그랬구요...
Mainframe MIPS를 x86 CPU 성능으로 역산하기도 쉽지 않을 뿐더러
동시에 여러 Guest OS들이 운영 중일 때는
역산해서 예상한 CPU 성능들의 합보다 나오지 않아 애를 먹었습니다.
벌써 7년이라는 세월이 흘렀고 이제는 z10에 linux를 올리네요...
제가 위에서 언급했던 문제들만 잘 해결이 된다면
앞으로는 zlinux도 대박을 터뜨리지 않을까 싶습니다.
오랫만에 보는 zlinux 기사 반가워 이렇게 포스팅 해 봅니다.
긴 글 함께 해 주셔서 감사합니다.
==============================================================

박재화 부장님이 코멘트 달아주신 대로 잘못된 부분을 수정합니다.
왜 저는 z/OS 위에 z/VM을 올렸었다고 왜곡된 기억을 가지고 있는지...;;;
Twitter : GomTaengEe
Trackback URL : http://mooa.net/tc/trackback/1813
rss
2003년, 참 오래 전 이야기입니다. ^^ 누구시더라... ㅎㅎ
말씀하신 것처럼 당시에는 각 ISV 업체들이 zLinux에 대한 가격정책도 불분명했고, 또한 z990의 CPU도 리눅스 워크로드를 돌리기에는 너무 느리게 느껴졌었습니다. z/VM은 지금처럼 Linux를 운영하기 위한 메모리 공유 및 활용 방안에 대한 기술이 미처 제대로 적용되기도 전이었습니다. 그런 탓에 TCO 측면에서 보면 여러가지로 불리한 부분이 있었습니다.
하지만, 지금은 상황이 많이 바뀌었습니다. 4.4GHz의 CPU를 장착한 System z10이 나오고부터는 리눅스에서 돌아가는 많은 어플리케이션들도 굉장히 빠르게 구동됩니다. z10 부터는 System p의 CPU 개발자들과 함께 CPU 설계를 했다는 소문도 있습니다. 그 배경에는 그 위에 탑재되는 리눅스의 성능을 최대로 끌어올리기 위한 부분도 포함되어있었으리라 생각합니다. z/VM 쪽에도 많은 부분의 메모리 공유 및 활용 방안이 리눅스와 긴밀하게 적용되어 있습니다. 상황이 많이 좋아졌단 얘기죠. ㅋㅋ ISV 쪽도 현재는 유닉스에서 책정하는 가격을 그대로 적용하고 있습니다. 코어단위로 받죠. 오라클 서버의 경우 2 IFL에 5개 리눅스를 돌리건, 10개를 돌리건 가격은 2개의 CPU에 대해서만 적용이 됩니다.
이젠 많이 달라졌으니, 대박을 치겠죠? ^^
사실 대박을 친다기보다는 기사에도 있듯이 많은 리눅스 개발자나 운영자들이 좀 더 핵심 업무에 다가갈 수 있는 기회로 삼을 수 있게 되길 희망해봅니다.
참, 한가지 오류가 있어 정정하렵니다.
z/OS위에 z/VM이 설치되는 것이 아닙니다. 오히려 그 반대죠. z/OS는 운영체제에 대한 가상화 기능은 없습니다. z/VM이 그런 역활을 할 수 있어요. 그래서 z/VM 위에 z/OS 혹은 리눅스 서버들을 돌리게 되는 것이죠. 2003년 당시에도 그랬는데. ^^ z/VM에도 z/OS에서 사용하는 것과 동일한 RACF 과 같은 보안관리자가 그대로 돕니다. 국내 고객들 중에도 가상 리눅스 서버들의 하이퍼바이저 단의 보안을 위해서 z/VM 상에 RACF을 사용하는 곳도 있지요. :-)
아무튼 예전의 관심, 지금도 기억해주셔서 감사감사~ ^^
그리고 리눅스는 z/vm 없이 단독으로 LPAR에 설치해서 사용할 수도 있습니다. 이럴때에는 하나의 LPAR에 하나의 리눅스만 운영할 수 있습니다. 정리하면, 메인프레임에서 리눅스를 사용하려면 z/vm위에서 동작하도록 하는 방법과 리눅스를 단독으로 사용하는 방법이 있습니다.
물론 z/vm을 사용하는것이 훨씬 효율적이고 메인프레임의 여러 기능도 더 잘 사용할 수 있습니다. 가상화 뿐만 아니라, 예를 들면 네트워크 인터페이스를 여러개로 묶어서 가상의 switch처럼 이용할 수 있는 vswitch, RACF으로 보안을 강화한다던지...짧은 글로 설명하기 어려운 많은 장점들이 있습니다.
작년에 BC카드 차세대에서도 메인프레임과 유닉스를 경합하였고 결국 비용과 성능 측면에서
유닉스가 더 효과적이라는 결론으로 IBM UNIX로 선정된것으로 알고 있습니다.
메인프레임에 z/VM 그리고 다시 거기에 WAS와 Java Application을 통한 차세대급이 과연 적요이 가능한지 부터가
전 의문스럽습니다. 국내에 한곳도 그러한 사례가 없으니까요.
제가 경험한 차세대인 S생명은 java class 파일만 8만개정도됩니다. 또한 다양한 프레임워크와 솔루션 제품들이
과연 z/VM에서 정상적으로 동작하는지도 사실 의문스럽기만 합니다.
아마 동부화재는 수많은 제품들에 대해서 각기 검증과 연동시 문제점을 하나하나 찾아봐야할 것같습니다.
제가 술 사주신다는 말씀은 절대 놓치지 않습니다.
ㅎㅎ
약도와 편하신 시간을 알려주시면 언제라도...
sel2 at dreamwiz.com