김건우 전문과장 한국아이비엠 대형시스템 사업본부
김건우 전문과장 한국아이비엠 대형시스템 사업본부
연/재/목/차
1회: IBM eServer - zSeries의 현재와 미래(이번호)
2회: IBM eServer - 새로운 패러다임, z/OS와 Linux for zSeries(11월호)
3회: IBM eServer - zSeries 솔루션 포트폴리오(12월호)
1. IBM eServer zSeries990의 발표로 보는 H/W
아키텍처의 발전
zSeries의 아키텍처의 발전
금년 5월12일, 한국아이비엠은 IBM eServer zSeries990(이하 z990)을 발표했다. IBM zSeries 서버는 그 원조격인 IBM S/360의 아키텍처를 기본으로 발전하여 왔다. 아키텍처를 사전에서 인용하면, 건축기술로 번역할 수 있지만 계산기의 하드웨어에서는 명령셋이나 지원하는 하드웨어의 최대수, 지원방법 등을 의미한다. 단, 아키텍처상의 수치와 실제 사양은 그 당시의 기술이나 판매가격등을 고려하여 결정되므로 반드시 아키텍처상의 한계까지 실현하는 것은 아닌 것이 보통이다. 여기에서는 S/360부터 어떻게 zSeries의 아키텍처가 발전하여 왔는지 그 일부를 소개한다.
S/360 아키텍처의 진가
아키텍처라는 말이 전자계산 분야에서 사용되어진 것은 S/360(1964년 발표)이 최초라고 해도 과언이 아니다. S/360아키텍처에서 가장 중요한 것은 '패밀리'라는 개념이다. S/360 출현 이전의 계산기는, 과학기술계산용(워드 머신계)과 상업계산용(캐릭터 머신계)의 2종류가 제조, 판매되고 있었다. S/360은, 양자를 동일 계산기상에서 실행할 수 있도록 새로이 바이트라는 개념을 도입함과 동시에, 소형기에서 대형기까지 동일 명령셋을 장비하여 확장성과 동시에 연산기구의 가상화를 실현하였다. 이 개념이 '패밀리'라고 말하는 것으로, 이 개념과 기본 명령셋은 현재의 z990까지 이어지고 있다.
실기억영역과 가상기억영역의 확대
S/360은 24비트 어드레싱으로 실기억영역만을 지원하였다. 이로 인해 실장할 수 있는 실기억영역은 16MB로 제한되어 있어 OS를 포함한 모든 프로그램은 16MB의 실기억영역으로 가동하였다. S/370 XA(1983년 발표)에서는 31비트 어드레싱이 실현되어, 사용가능한 실기억영역과 가상기억영역이 2GB까지 확대되어 보다 큰 애플리케이션의 실행이 가능하게 되었다. S/370 XA에서 가상기억영역의 상한선이 2GB로 설정된 이유는 24비트 어드레싱의 애플리케이션과의 호환성을 유지하기 위해서다. 2GB라는 것은 프로그램에 있어서는 광대한 공간이지만, 데이터를 저장하기 위해서는 역시 적은 공간에 지나지 않는다. 예를 들어 1건당 2KB의 고객데이터를 150만건 메모리에 전개하기 위해서는 3GB의 공간이 필요하다.
z900(z/Architecture, 2000년 발표)에서는 64비트 어드레싱을 실장하여 16엑사바이트까지의 실기억영역과 가상기억영역이 직선적으로 사용가능하게 되었다. 특히 운영체계인 z/OS상의 유닉스시스템 서비스에서는 64비트 어드레싱을 활용하여 보다 많은 데이터를 메모리상에 전개할 수 있어 고속의 데이터처리가 가능하게 되었다. 애플리케이션을 만드는 면에서 보면, 데이터가 모두 메모리상에 있는 것을 전제로 설계가 가능하여 프로그램 로직이 단순하게 되어 개발효율의 향상으로 이어진다고 단언할 수 있다.
채널이라는 개념
zSeries에는 유닉스서버에는 없는 기구로써 채널이라는 H/W가 있다. 채널이란 CPU와는 독립하여 움직이는 자체CPU를 갖는 H/W로써 CPU와 I/O 제어장치간에 있어 지정된 입출력명령(CCW, Channel Command Word)를 순차실행하여 I/O 장치의 제어와 데이터 전송을 행하는 것이다. CPU는 I/O처리를 위해 일련의 CCW를 작성하여 채널에 대해 처리를 의뢰한다.. 예를 들어 디스크에 대한 대표적인 CCW는 아래와 같다.
· Seek：디스크의 헤드를 읽고 쓸 트랙으로 이동한다
·Set File Mask：헤드가 이동하지 않도록 이후의 Seek명령을 거부시킨다
·Set Sector：읽어야 할 트랙상의 데이터 위치(섹터번호)를 지정한다
·Search/TIC：데이터가 헤드에 도달하기까지 디스크의 회전을 유지한다
·Read/Write：데이터를 읽고 쓴다
·Read Sector：전후 트랙상의 장소를 읽어 다음 입출력명령에 대비한다
채널은 이들 CCW를 순차실행하여 모든 CCW가 종료하면 CPU에 대해 I/O할당을 제시하여 CCW의 종료를 전달한다. 이 사이 CPU는 다른 업무처리에 전념할 수 있다. S/360이나 S/370시대는 채널은 CPU와는 다른 박스에 설치되었지만 현재의 zSeries에서는 SAP(System Assistance Processor)라는 전용 프로세서에서 이 기능을 실현하여 대폭적인 설치면적의 절감과 데이터 전송속도의 향상을 도모하고 있다.
채널 수의 확대
S/360에서는, 물리적인 I/O장치를 식별하기 위해 3자리의 16진수(설명상 cdd로 표시함)을 사용하여, c를 채널번호, dd를 I/O제어장치와 I/O기기의 식별번호로 정의하여 왔다. 이 때문에, 접속가능한 채널수도 CPU당 16개로 한정되어 있었다. 채널패스는 특정 I/O제어장치와 접속되어 있어, 채널패스의 선택은 현재의 UNIX와 같이 OS가 행하여 왔다. 또한 데이터의 전송과 I/O의 종료를 표시하는 I/O작업은 CCW를 받은 채널패스에서만 가능하였다.
이후 S/370 XA는 동적 채널 서브시스템으로써 "채널의 가상화"를 실현하여, CPU는 물리적인 I/O장치번호가 아닌 4자리의 논리번호로 I/O가 행하여지도록 되었다. 논리적인 I/O 번호와 물리적인 I/O 장치와의 대응은 OS와 독립한 IOCP(I/O Controll Program)에 의해 행하여진다. 이 개혁에 의해 사용가능한 채널수도 서버당 256개로 대폭 확장되었을 뿐만 아니라 채널의 가상화에 의해 모든 CPU에서 I/O장치가 인식될 수 있게 되어 OS는 채널 패스선택의 업무에서 해방되었으며, 데이터전송이나 I/O작업은 비어있는 어떤 채널 패스에서도 행해질 수 있게 되었다. 소위 I/O의 블랙박스화라고 할 수 있다. 이 기구에 의해, CPU는 보다 업무처리에 전념할 수 있게 되어 S/360의 I/O아키텍처에서는 채널의 사용율의 한계를 거의 30％로 설계되어 있던 것을 50％를 넘어서도 같은 퍼포먼스를 얻을 수 있게 되었다. 또한 동적 채널 서브시스템은, I/O장치나 채널의 사용율을 정확하게 파악할 수 있는 기구도 장비하고 있다.
이번 z990의 발표에 의해, 약30년에 걸쳐 서버당 채널수가 256개라는 한계를 넘어섰다. 장래의 z/OS와 z/VM는 1024개가 넘는 채널을 지원할 예정이다. 좀더 높은 성능의 CPU를 효율적으로 움직이기 위해서는 여기에 맞는 I/O 대역폭이 필요하며, 당연한 것처럼 보이지만, 이 벽을 넘기위해서는 H/W와 OS의 대폭적인 개량이 필요하였으며 이것이 zSeries에의 지속적인 연구개발투자의 큰 성과라고 할 수 있다.
LPAR수의 확대
하드웨어에 의한 논리분할이 발표된 것은 1988년이지만, 초기 단계에서는 최대 7개의 LPAR(Logical Partitioning)가 지원되었다. ESA/390에서 15개 LPAR가 지원되었지만 오랫동안 이 상태가 이어져왔다. 이것은 LPAR ID를 16진수 1자리수 밖에 사용하고 있지 않았기 때문이다. 비용을 얼마나 절감하는가는 고객의 큰 과제이다.
H/W의 성능 향상과 TCO 절감을 실현하여, 보다 많은 시스템을 통합가능하게 하기 위해 이 제한을 완화시킬 필요가 생겼다. z990에서는 LPAR ID를 2자리수로 하여 30개의 LPAR(장차 60개까지 확대예정)까지 지원하게 되었다. 이 개량으로 인해 보다 많은 서버를 통합하여 TCO를 절감할 수 있게 되었다.
2. zSeries에서의 Autonomic Computing 대응기술
e비즈니스를 지원하는 서버의 요건
e비즈니스를 지원하는 서버에는 24시간 365일 연속 가동하는 높은 가용성이 요구된다. ZSeries는, 오랜기간에 걸친 H./W와 S/W에서의 기술개량에 의하여 단일 서버에서 높은 가용성을 실현하고 있다.
zSeries의 모체인S/360의 시대(1964년 발표)는 'RAS'의 사고방식의 기본인 단일 시스템의 신뢰도를 향상시켜 왔다. 또한 70년대에 'IS' 2문자를 추가하여 RASIS로써 보다 신뢰성이 높은 제품을 제공하여 왔다. RASIS란 Reliability(신뢰성), Availability(가용성), Serviceability(보수용이성), Integrity(보전성), Security(기밀성)을 의미한다.
이 RASIS를 재정의한 것이 'Autonomic Computing'에서 정의되어 있는 4가지의 기술이라고 할 수 있을 것이다. 확인을 위해 이 4가지의 기술을 들어보겠다.(CHOP라고 외울 수도 있다.)
·자기구성(Self-configuring)
·자기복구(Self-healing)
·자기최적화(Self-optimizing)
·자기방어(Self-protecting)
이 4가지의 기술을 단적으로 말하면, "24시간 365일 자율적인 자원관리에 의한 서비스를 제공하는 것"이라고 할 수 있다. 그러면, zSeries는 이들 기술을 어떻게 구체화하고 있는 것인지 알아보자.
자기구성의 기술
시스템이 자동적으로 환경변화에 적응하여 가기위한 기술이다. 이 대표적인 예로써는 CuoD가 있다. IBM eServer zSeries는, CPU는 물론, 채널, OSA, 메모리도 시스템을 정지하지 않고 증설 가능하다. 메모리를 포함한 CuoD를 제공하는 서버는 현시점에서는 극소수이다. 이미 MVS시대부터 제공되고 있는 입출력장치의 동적변경을 지원하는 동적 입출력 재구성기능(Dynamic I/O Reconfiguration)도 잊어서는 안되는 기술이다.
자기복구의 기술
시스템이 장해를 감지하여 시스템정지가 발생하지 않도록 자동복구하는 기술이다. zSeries는 S/360시대부터 정지하지 않는 시스템을 추구하여 왔으며 H/W와 S/W의 양면에서 가장 충실된 기능을 갖고 있다. 예를 들어, 메모리나 내부버스의 ECC기구에 의한 1비트에러의 자동복구와 2비트 에러의 검출을 들 수 있다. ECC는 최근에야 서버에서 거의 표준으로 장착되어 있으며 수년전까지는 장착되어 있지 않았던 기술이나 zSeries는 이미 S/360시대부터 구비하고 있다.
또한 메모리의 자기복구기능으로서는 정기적인 메모리 검사로 일시적 에러가 한계치에 도달한 메모리 칩에 재할당을 행하는 동적 메모리 어레이도 장비하고 있다.
CPU에 대해서는, 만일 장해가 발생해도 예비CPU에 투과적으로 (OS도 알 수 없는 사이에) 할당하는 동적 스페어링 기능이 있다. 이 기능은 CPU, SAP, CF, IFL에 적용된다.
기타, 이미 컴포넌트는 내장해설계가 되어 있어 단일 장해로 시스템이 정지하는 일은 없다. 이들 기구나 기능에 의해 zSeries의 MTBF(Meantime Between Failure, 평균장해간격시간)은 35년이상이라는 초고가용성을 실현하고 있다.
OS나 미들웨어에서는 FRR(Functional Recovery Routine)의 사고방식을 기초로, 프로그램 에러가 확산되지 않도록 각 모듈안에 장해복구를 행하도록 설계되어 있다. 만약 하위 모듈에서 장해복구가 불가능한 경우 보다 상위 모듈에서 장해복구를 실시한다. 아무리해도 장해복구가 불가능한 경우는 덤프를 채집하여 해당 프로그램을 이상 종료시키고 시스템의 전체장해가 되지 않도록 하고 있다. 이러한 기능은 UNIX나 Windows에서는 볼 수 없는 고도의 복구처리이다.
자기최적화의 기술
시스템이 자신을 감시하여 자동적으로 자원의 최적화를 행하는 기술이다. zSeries는 eServer에서도 가장 진보된 기능을 제공하고 있다. 타 시스템에 추종을 허락하지 않는 기능으로써는 논리분할기구, IRD(Intelligent Resource Director) 그리고 z/OS의 워크로드 매니저를 들 수 있다.
최근 논리분할기구는 유닉스나 IA서버에서도 장착되어 있지만, 대부분은 분할단위가 CPU나 시스템 보드단위의 물리분할이며 I/O(채널)의 구획간 공유가 불가능하다. zSeries의 논리분할기구는 1988년부터 제공되어 왔으며 CPU 능력을 퍼센트 단위로 분할할 수 있고, 구획간에서 CPU능력의 동적할당과 채널의 공유가 가능하다. 이것은 필요로 하는 시스템자원의 효율적인 이용에 이어지며, 비용절감이 가능하게 된다는 것을 의미한다.
이 논리분할기구를 더욱 발전시킨 것이 zSeries H/W와 이의 운영체계인 z/OS에서 실현되는 IRD이다.
논리분할된 1대의 서버안에서 구획별로 설정된 서비스레벨을 유지해야 하는 워크로드의 변화에 따라 시스템 자원의 배분을 동적으로 조정하는 기능이다. 이 기능은 오랜 기간에 걸쳐 배양된 논리분할기구, z/OS의 워크로드 매니저 그리고 병렬 시스플렉스 기술을 1대의 서버안에서 유기적으로 융합시킨 것이다. 결국, 1대의 서버를 다수의 구획으로 분할하여 병렬시스플렉스 기술을 응용한 기구를 조합하여 워크로드 매니저가 각 구획의 가동상황을 감시하고 설정된 서비스레벨을 유지하도록 CPU자원과 채널자원을 필요구획에 동적으로 배분하는 것이다.
이 기술은 현시점에서는 zSeries만이 제공할 수 있는 것이며, 시스템자원의 최대 활용, 시스템 프로그래머의 시스템 튜닝작업의 대폭경감, 워크로드의 변화에의 자동대응을 실현하여 적은 시스템자원으로 최대의 처리효율을 얻는 기법이라고 할 수 있다.
자기방어의 기술
한마디로 말하면, 안전한 시스템 가동환경을 제공하는 기술이라고 할 수 있다. zSeries는 원래 철저히 관리된 환경에서 운용되어 왔지만, 다수의 워크로드를 동시에 실행하기 때문에 시스템정지는 매우 큰 영향을 끼친다. 때문에 zSeries에는 유닉스나 IA서버에는 없는 메모리상의 데이터를 보호하는 강력한 방어기구로써 스토리지 키가 구비되어 있다.
1972년에 S/370이 처음 가상메모리를 장착하여 상용 메인프레임으로써 발표되었지만, 지금까지 프로그램은 모두 실기억장치상에 전개되어 왔다.(당시 실장되어 있는 메모리의 크기는 수십KB에서 수백KB에 불과) 스토리지 키는 실기억장치를 4KB단위로 분할하여 각 4KB에 4비트의 키를 부가시킨다. OS는 프로그램을 실기억장치에 전개할 때에 프로그램에 할당된 키와 동일 키를 프로그램이 사용하는 실기억영역에 할당한다. 실기억영역으로의 데이터 쓰기에는 실기억영역에 할당된 키와 PSW(Program Status Word, 다음에 실행할 명령을 가리키는 CPU내의 레지스터)내의 키, 결국 프로그램에 할당되어 있는 키가 동일한 경우에만 허가된다. 이 기구에 의해 다수의 프로그램을 실기억장치상에 전개하여도 상이한 키를 할당하면 다른 프로그램이 사용하고 있는 영역을 침범하는 일이 없다. 결국 1대의 서버안에서도 다수의 업무가 보호되는 환경을 만들 수 있다는 것을 의미한다.
이 개념은 가상기억기능이 실현된 현재에도 활용되고 있으며 OS의 컴포넌트별로 상이한 스토리지 키를 할당하여 OS가 자기 자신을 파괴하는 일이 없도록 하고 있다.
또한, 운영자나 시스템 프로그래머의 단순 실수로부터의 방어기능을 S/360시대부터 구비하여 왔다. 일례로 패스워드기능이 있어, 패스워드로 보호된 데이터셋은 액세스 시에 패스워드를 입력하도록 되어 있다.
또한 데이터셋에는 만료기한일(expiration date)이 지정가능하여 기한이전에 그 데이터셋에 변경이나 삭제요구가 행해진 경우, 운영자의 개입이 필요하도록 설계되어 있다. MVS에서 도입된 APF(Authorized Programming Facility)는 특권상태(supervisor mode)가 필요한 프로그램에 대해서 보다 강화된 보호기능을 제공하고 있다. 특권상황을 얻은 프로그램은 실행 모듈을 작성하는 시점에서 그 시기를 명시적으로 표시하고 또한 특정 프로그램 라이브러리에 등록할 필요가 있다. 결국, 그 특정 프로그램 라이브러리를 패스워드와 만료 기한일에 의해 관리하면, 실수로 특권상황을 얻는 프로그램을 시스템상에 등록할 수 없게 되며 공히 그 실행을 관리 할 수 있다.
또한 유저인증, 데 이터셋 자동보호, 테이프 볼륨의 기밀보호, 트랜잭션 보호 등 기업 레벨에서 일원화된 기밀보호가 가능한 프로그램 제품인 RACF(Resource Access Control Facility)를 업계에 선구적으로 제공하여 통일된 기밀보호기능을 제공하고 있다. 현재 RACF는, LDAP의 기능을 포함하여 단순히 1시스템의 기밀보호만이 아닌 인증국의 기능도 제공할 수 있다.
H/W의 대응을 보면, 기간시스템으로써 최초의 암호화기구를 표준으로 장착하였다. 현재는 e비즈니스 기반을 더욱 강력하게 지원하기 위해 SSL처리의 성능향상이나 각종암호화 알고리즘에의 대응등을 적극적으로 구비하고 있다. zSeries의 고가용성은, 어느 날 돌연히 출현한 것이 아니라 꾸준히 기술발전을 거듭하여 온 결과라는 것을 이해하여 주시기 바란다.
3. 오픈 시스템의 참모습
시스템 구축환경의 변화
시스템의 재구축이나 확장이 필요한 경우 중 많은 경우에 '오픈 환경에서는 키워드가 들어가 있다. 이 키워드를 본 순간 '유닉스로 구축'이라는 선입관을 갖게 되지는 않는 걸까? 한번 더 원점에서 다시 '오픈 환경'에 기대되고 있는 것은 어떠한 것인가를 생각해봐야 할 것이다.
몇 번이나 안건을 조정하여 보면 '오픈 환경'에 기대되고 있는 것은 이외로 한정적이며 아래와 같이 정리할 수 있다.
·TCP/IP가 표준으로 실장되어, 각종 시스템과 용이하게 접속가능하다
·업계표준(시장표준)의 미들웨어를 사용할 수 있다
·클라이언트가 GUI환경이 된다
·자바, C/C++등 새로운 개발언어를 사용할 수 있다
·개발생산성의 향상과 금후의 확장성이 있다
·비용절감이 실현된다(기능이 아님)
이들 기대되는 기능은 모두 zSeries와 z/OS에서 실현되어 있는 것이며, 극언하면, 기대효과는 '비용절감'이라고 할 수 있을 것이다.
진정한 오픈 시스템이란
지금 가용되고 있는 운영체계(OS)를 정리해보면,
·z/OS를 대표로 하는 소위 메인프레임 OS
·유닉스. 썬의 솔라리스, HP의 HP-UX, IBM의 AIX가 대표격
·마이크로소프트의 윈도우즈
·오픈 소스인 리눅스
일반적으로 유닉스=오픈이라고 생각하고 있지만, 현재 많은 환경에서 사용되고 있는 유닉스는 H/W 벤더 고유의 유닉스이다. 그러나, 오픈 환경에 기대되고 있는 기능이 제공되고 있는 점에서 보면, 광의의 오픈 OS라고 할 수 있다. 이 정의에서 보면 z/OS도 Open OS라고 할 수 있다.
그러면, 진정한 오픈 OS란 무엇일까? 현시점에서 정확히 오픈 OS에 근접한 OS라고 하면, 소스 코드가 공개되어 있는 리눅스나 FreeBSD라고 할 수 있다. 그러면, 소스 코드가 게시되어 있는 솔라리스나 윈도우즈도 오픈 OS라고 할 수 있는 것일까? 대답은 부정적이다. 왜냐하면, 소스 코드는 게시되어 있지만, 사용자가 자유롭게 변경하는 것이 불가능하고, 공개되어 있는 코드가 현재 사용되고 있는 시스템의 OS 코드와 동일하다는 보장이 없기 때문이다. 이 때문에 코드상에 오류가 있어도 사용자가 직접 수정할 수 없고, 결국OS를 제공하고 있는 벤더에게 수정을 의뢰하게 된다.
진정한 오픈 시스템을 구축하기 위해서는 OS만이 문제가 아니라, 이 위에서 가동하는 데이터베이스나 트랜잭션처리용 미들웨어에 관해서도 같은 고려해야 할 필요가 있다. 결론부터 말하면, 진정한 오픈 시스템을 구축하는 것은 쉽지 않음을 알 수 있다. 또한 진정한 오픈 시스템이 구축되었다고 해도 이것을 유지관리하기 위해서는 상당한 기술력과 체력이 필요하여, 현실적으로는 특정 고객이나 한정된 환경에서만 적용할 수 있다고 할 수 있다.
그러면, 특별한 체력을 필요로 하지 않고 '오픈 환경'의 시스템을 만들기 위해서는 어떻게 하면 좋을까? 앞에서도 서술한대로 기대되고 있는 오픈 환경의 정의는 일반적인 내용이며, 상용 OS의 상당수가 이미 대응하고 있음을 알 수 있다. 달리 말하면, 어떠한 상용OS를 선택해도, 거의 지장이 없다고 말할 수 있다. 가장 중요한 점은, 장래의 확장성이나 영속성이 보장됨과 동시에, 혼재한 시스템간의 접속성이 간단할 것이다 이것을 실현하기 위해서는 시장에서 널리 이용되고 있는 업계표준의 OS나 리눅스를 채용하는 것이다. 이러한 사고방식은 미들웨어나 운용관리, 개발환경의 선정에서도 적용된다.
오픈 시스템으로서의 zSeries와 z/OS
zSeries나 z/OS의 역사에 대해 말하는 것은 생략하고, zSeries와 z/OS의 개방성에 대해 다시 한 번 서술하겠다.
우선, H/W로써의 zSeries를 보면
·TCP/IP환경을 실현하는 OSA의 표준장비
·OSA에서의 IPv6의 지원
·SSL이나 T-DES를 시작으로 하는 각종 암호 알고리즘에 대응한 암호화기구
·인텔에서 채용하고 있는 IEEE표준부동소수점 기구
·TCP/IP나 UNIX（C언어）를 고속으로 실행하기 위한 명령셋
등이 이미 장비되어 있다. 또한, zSeries H/W상에서 리눅스가 직접가동 된다.
한편 z/OS는
·IPv6를 지원하는 TCP/IP의 표준실장
·UNIX95브랜드를 취득하고 있는 유닉스 시스템 서비스. 당연히 자바, C/C++도 지원하고 있음
·Infoprint Server에 의한 네트웍 프린터로의 출력
·XML, LDAP, 유니코드에의 대응
·SMB서버에 의한 윈도우즈 환경에서의 파일/프린트 서버 기능의 제공
등, 오픈이라고 할 수 있는 업계표준기능이 실장되어 있다. z/OS에서 지원하는 64비트 어드레싱도, z/OS의 성능향상만이 아닌, 유닉스에서의 애플리케이션의 이식의 용이성을 실현한 것이라고도 할 수 있다.
오픈 시스템 구축의 고려 사항
마지막으로, 유닉스를 사용하여 광의의 오픈 시스템을 구축할 때의 고려 사항에 대해 생각해보자.
첫번째는 일반적으로 사용되고 있는 유닉스(썬 솔라리스, HP-UX, AIX）가 벤더 고유의 유닉스인 것이다. 이것은 제품으로써의 품질을 갖는 의미에서는 중요한 것이지만, H/W의 선택의 폭이 적어지게 되는 측면을 갖고 있다.
두번째로는 이 유닉스상에서 가동하는 미들웨어를 들 수 있다. IBM을 제외한 상기 2개사는, H/W와 OS는 제공하고 있지만 미들웨어는 제공하고 있지 않다. 이 때문에, OS와 미들웨어와의 정합성의 확인은, 고객주도로 행하지 않으면 안된다.
세번째의 고려 사항은 하나의 유닉스 시스템상에서는 단일 워크로드만 실행되도록 시스템을 구축하는 것이 일반적인 것이다. 이것은 단순히 서버수의 증가만이 아닌, 서버별로 OS나 미들웨어의 레벨이 상이하거나 다른 미들웨어가 사용될 가능성이 높게 되어, 관리항목이 증가하는 것을 의미하고 있다. 또한, 서버간의 능력이나 자원배분을 동적으로 행하는 것이 어려운 것이 현실이므로 자원의 효과적인 활용이 어렵다. 달리 말하면 자원의 낭비가 발생한다고 할 수 있다.
마지막으로 어떤 유닉스 시스템상에서 개발된 애플리케이션이 다른 유닉스 시스템에 간단히 이식가능하지 않은 점이다. 만약 이식성을 최대로 하는 것이 목표하면, 모든 유닉스에서 공통으로 제공하고 있는 기능만 사용해야 하며, 이것이 애플리케이션 개발의 생산성이나 성능에도 영향을 줄 것이 분명하다.
유닉스에서 시스템을 구축하는 경우 TCA（Total Cost of Acquisition, 초기구입액）은 저가로 할 가능성이 높지만, 수년간의 TCO（Total Cost of Ownership）를 본 경우에 이 선택이 최적일지를 종합적으로 판단한 시스템 선정을 행할 필요가 있다.