월: 2010 12월

IFL에 도대체 몇 개의 리눅스를???

요즘 하도 뜸해서 글 하나 써볼까 합니다. 🙂

Linux on System z 메일링 리스트에 “하나의 IFL에 도대체 몇 개의 리눅스 서버들을 돌릴 수 있을까요?”라는 질문이 올라왔습니다. 아~ 늘 느끼는, 그리고 늘 궁금한 내용의 질문입니다. 그 쓰레드를 읽고 인용하고, 정리를 해봤습니다.

국내 한 고객사는 IFL 6개를 가지고 있고 그 위에 약 60개가 넘는 리눅스 서버들을 운영하고 있습니다. 그 리눅스 서버들 중 몇몇은 꽤 큰 업무를 돌리고 있지요. 전체 IFL의 약 30% 정도의 사용률을 보입니다. 또 다른 고객사는 IFL 3개에 리눅스 서버 5개를 돌리고 있고, 사용률은 70%에 육박합니다.

메일링 리스트에서도 누군가가 이렇게 답했습니다.

z9 시스템에 2개의 IFL에서 약 100개의 개발 및 테스트 서버가 돌고 있고,
z10 시스템에 6개의 IFL에서 12개의 프로덕션 서버가 돌고 있습니다.
질문에 대한 답은 2에서 50, 혹은 z196이라면 2에서 150이라고 할 수 있어요.

🙂 맞는 답입니다.
사용자가 돌리는 어플리케이션이 무엇이냐에 따라, 또 사용자가 얼마냐에 따라, 서버마다의 피크가 같냐 다르냐에 따라 등등 수 많은 변수에 따라서 이 질문에 대한 답은 달라질 수 있겠지요.

그래도, 평균 잡아서 답을 낸다면 어느 정도인가요? 라고 하신다면…

메인프레임 환경과 서버 환경에 대해서 한 10가지 정도로 비교를 한 글을 잠깐 인용해보겠습니다.

1. 재해 시 복구는 메인프레임쪽이 훨씬 쉽습니다. 사실 하드웨어가 무엇으로 바뀐다해도 모두 똑같거든요. 하지만, PC 타입의 서버들의 경우에는 하드웨어가 바뀌면 소프트웨어 드라이버도 바뀌어야합니다. 이것이 단순히 백업 받은 것을 부어넣는 대신 소프트웨어를 재설치해야하는 이유지요. 😦

2. I/O 서브 시스템. FICON/FCP를 장착한 메인프레임은 초당 수백, 수천의 I/O를 처리할 수 있습니다. 만일 초당 몇 백정도의 I/O 처리만 필요하다면, PC 급이 처리할 수 있는 범위 안에 들겁니다.

3. 라이센스는 양날의 검입니다. 하나의 IFL에 5개의 오라클 서버를 돌린다면, 단순히 하나의 카피만 지불하면 됩니다. 하지만, 만약 서버 하나만 필요한 제품들이 많고, 이들 때문에 IFL 수가 더 필요하게 된다면… 이들 제품에 대한 비용이 증가하게 될 것입니다. 적은 수의 IFL에 같은 제품의 서버들이 많아져야 된다는 얘기죠.

4. 디스크는 디스크일 뿐입니다. 큰 디스크 장비나 작은 디스크 장비나 또는 CKD로 구성하던지, SCSI 디스크로 구성하던지 비용은 비슷하거나 동일합니다.

5. 메인프레임 메모리는 더 비쌉니다. 하지만, 훨씬 효율적으로 사용됩니다. 어플리케이션이 구동하는데 필요한 메모리가 4GB라면, 500MB를 할당해서 시작하고 어플리케이션이 필요로할 때마다 늘려줄 수 있습니다.

6. 서버 어플리케이션이 더 많은 자원들을 필요로 할 때마다 대부분의 경우 새로 나온, 훨씬 더 큰 서버들을 사야합니다. 메인프레임 서버가 더 많은 자원들을 필요로 할 때에는 다른 서버들의 자원들을 빼앗아 올 수 있습니다. 또 그 규모가 좀 크다면, Capacity on Demand 옵션을 사용해볼 수도 있습니다.

7. 그린 컴퓨팅. 늘어나는 서버들을 메인프레임 환경으로 통합하고, 그 환경 하에서 효율적으로 자원을 배분해서 사용한다면 현재의 데이터센터에서 서버들이 차지하고 있는 상면을 훨씬 더 줄일 수 있을 겁니다.

8. 내부 네트워크 속도. 네트워크에 연결된 여러 서버들의 사용이 필요한 어플리케이션의 기능이 있다고 한다면, 네트워크 때문에 이 기능 자체가 느려질 수 있습니다. HiperSockets이나 Guest Lan/VSWITCH(z/VM 하의)를 사용한다면 전혀 문제될 것이 없습니다. 서버들 간의 엄청난 속도의 통신이 가능해지죠.

9. 성능 측정/분석 도구가 필요합니다. 메인프레임의 경우 LPAR 단위로 구매할 수 있겠지요. 서버 환경의 경우에는 서버 하나당 제품 하나씩 구매해야겠지만. 그래도 여전히 몇몇 특화된 성능 툴(예를 들어 Oracle OEM 같이 오라클 내부 성능에 대해 측정해주는)에 대해서는 별도로 구매해야할 지도 모릅니다.

10. PC 서버들의 가장 심각한 문제는 컨텍스트 스위칭입니다. 아주 엉망이죠. 메인프레임은 이것에 대해서는 아주 훌륭합니다. CICS 트랜젝션 같은 것들이 훌륭히 처리하고 있죠. 만약 여러분의 업무가 배치성(데이터 마이닝 같은)이 아니라 트랜잭션성이라고 한다면, PC 서버들은 이것을 위해서 설계된 것이 아닙니다. 유닉스 서버들이라고 하면, 좀 더 낫겠지요.

메인프레임에 리눅스가 처음 발표되고 IFL이 공개되었을 2000년 당시에는 IFL 하나 당 약 100개의 리눅스 서버 이미지를 운영하는 것에 대한 논의가 있었습니다. 이 서버들 대부분이 라우터나 DNS, Samba, NFS 그리고 몇몇의 웹서버들이었지요. 지금은 IFL 당 10-20개의 실제 워크로드들이 돌 수 있을 것이라 봅니다.

다른 얘기 하나 더. 메인프레임 업그레이드 방식 중에 하나의 구형 시스템 박스에서 다른 신형 시스템으로의 MES 업그레이드라는 게 있습니다. 구형 장비인 z9 서버에서 z10 혹은 z196 서버로 MES 업그레이드를 할 경우에 IFL에 대한 라이센스가 함께 옮겨갑니다. 이런 경우에는 리눅스 쪽의 라이센스들은 새로 구매할 필요가 없다는 얘기가 됩니다. 게다가 새로운 IFL은 구형 IFL에 비해서 훨씬 더 빠른 성능을 가지게 됩니다. 서버 환경에서 버려지는 이런 비용들은 메인프레임 환경에서는 없어지는거죠.

하나의 IFL에서 몇개의 리눅스를 돌릴 수 있는가도 중요하지만, 도입과정에서 또는 운영과정에서 시스템 구성(통합 운영하는 리눅스 서버들의 배치나 업무 비율 등)을 잘 설계한다면 훨씬 더 비용 효율적인 데이터센터 운영이 가능해지지 않을까 생각해봅니다.

Advertisements

여러 장비에서 z/VM IPL 할 때

DR센터 등 원래 설치된 장비와는 다른 여러 장비에서 IPL할때 환경 설정 방법입니다.

1. SYSTEM CONFIG 에서 SYSTEM ID를 설정할 때 System_Identifer_Default statement에서 CPUID로 서로 다르게 지정합니다.

SYSTEM_IDENTIFIER_DEFAULT UNDEFND
SYSTEM_IDENTIFIER * %%1341 ZVMCS1
SYSTEM_IDENTIFIER * %%0D06 ZVMCS3

CPUID는 Query CPUID 명령으로 확인해서 나오는 문자열의 3번째부터 6자리입니다.
CPUID= aassssssccccdddd
aa
identifies the version code. These two digits are set to X’FF’ to identify that your virtual machine is running under z/VM.
ssssss
identifies the processor. This field contains six hexadecimal digits. This is the only part of the CPUID that can be modified by means of the SET CPUID command or set by the system directory’s OPTION control statement.
cccc
identifies the model number. This field is set to the model number of the real machine.
dddd
identifies the machine check extended logout length. For z900 and z800 servers, this field is set to X’0000′. For all other supported servers, this field is set to X’8000′.

2. TCP/IP 설정은 기본적으로 SYSTEMID TCPIP 파일이 있으면 PROFILE TCPIP보다 먼저 인식합니다.

ZVMCS1 TCPIP
ZVMCS3 TCPIP

3. system config 에서는 System ID : 다음에 설정을 하면 해당 system ID로 IPL했을때만 적용되는 것으로 보이는데
추가 테스트가 필요합니다.