Category Archives: Technology

Tech #4 : VMware VSphere 4.1의 Network 구성

VMware VSphere 4.1에서는 Network의 자원 관리를 보다 적절하게 실현하기 위한 기능으로 “Network I/O Control”가 도입되었다고 한다. 또, NIC Teaming의 Load Balance Algorizm 으로 “Load Based Teamin”이라고 하는 신 Algorizm이 이용가능하게 되었다고 한다.

일단, 이전의 ESX(Classic)은 가상화을 행하는 “VMKernel”의 영역과 관리기능을 제공하는 “Service Console” 영역이었으나, Server의 처리 능력 향상에 비례하여, 가상 Machine의 집약 능력도 향상하는데 이는 보다 광대역의 Network 환경이 요구된 다는 걸 의미한다. 그걸 말해 주듯 이제 10Gbits Internet도 보급되기 시작했고, 10Gbits EtherNet의 Controller나 Switch를 포함하는 Blade Server도 등장하여 본격적인 궤도에 올랐다고 볼 수 있다.

10Gbis Ethernet의 사용을 전제로 System을 구축 할 경우 여러가지 Data 통신을 통합하는 시도도 많아 질 수 있고, 가상 Machine이 이용하는 Network를 포함한 관리 Network, iSCSI나 NFS 등의 Storge Network, vMotion이나 VMware FT가 이용하는 Data Transfer 등도 통합 해야 할 것이다. 통합을 위해서는 다른 Resource에 의해 대부분의 Performance가 점유되어 가상 Machine 전체가 Slow down 되는 경우를 피해야 하고, 그에 맞는 설계를 할 필요가 있다.

여기서, Network 자원 관리가 중요 해 지는데, Previous Version에서도 “Traffic Shaving”란 기능을 제공 했었고, 이건 가상 Port 또는 Port Group가 이용가능한 대역의 상한치를 지정하는 기능으로, 표준 가상 Switch에서는 Outbound Traffic, 분산가상 Switch에서는 Inbound, Outbound Traffic 가각의 Traffic에 대한 설정이 가능, 단 Traffic Shaving은 간단하게 이용가능한 상한치를 제어하는 기능 뿐으로 Unused 대역에 대한 다른 용도로의 전환은 불가능 하다. 아래 그림 처럼 Unused 영역이 있어도 상한치 이상을 사용 할 수 없다.

 

보다 이상적인 Network 자원 관리를 실현 하기 위하여 자원의 간섭이 있을 시, 미리 설정을 해 둔 비율로 Balance를 맞춰, 자원이 비어 있는 상황에서는 그 자원을 필요한 용도로 전환 하는 것이 가능 해야 한다. 아래의 그림과 같다.

 

CPU자원과 Memory 자원에 관해서도 위와 같은 자원 관리 구성이 Previous Version에 대해서도 제공 되었다. vSphere 4.1에서는 Network 자원에 관한 동일한 기능이 제공 되어 지는데, Network I/O Control이 그것이다.

Network I/O Control

vSphere 4.1의 new function “Network I/O Control”은 앞에서 설명 했던 것 처럼 유연한 Network 자원 관리를 실현하는 메카니즘이고, 현재 Enterprise Plus Edition에서 제공하고 있다. 또, 이 기능은 분산 가상 Switch 상에서 제공되는 기능이고, 표준 가상 Switch상에서는 이용 할 수 없다.

Network I/O Control에서 Network Traffic을 아래와 같이 6 class로 구분할 수 있다.

  1. FT Traffic
  2. iSCSI Traffic
  3. vMotion Traffic
  4. Management Traffic
  5. NFS Traffic
  6. Virtual Machine Traffic

User는 각각의 Class에 대해 “Limit” 혹은 “Share”라는 값을 설정 할 수 있고, “Limit”는 해당 Class가 사용 가능한 최대치이고, Mbps로 설정한다. “Share”는 “자원 간섭이 있을 시 Balance 값”으로 1 ~ 100의 정수값을 설정한다.

Network I/O control의 동작

Network I/O Control은 ESX로부터의 Outbound Traffic에 대해서만 유효하고, Inbound Traffic은 제어 대상이 아니다. 또, “Share 값의 계산은 최종적으로 각 ESX Host 단위” 도 주의 할 점이다. 분산 가상 Switch를 구성할 경우, 보통 각 ESX에 구성하는 Uplink의 수나 물리 Adapter의 대역등은 공통이지만, 그렇지 않은 경우는 주의가 필요하다. 1Gbps의 NIC으로만 구성되는 Host와 10Gbps의 NIC을 보유하는 Host가 같이 있는 경우는 Share 값의 계산 결과로 확보되는 대역이 Host에 따라 다른 경우가 있다. 

“Limit”나 “Share”의 설정은 동시에 유효화가 가능하고, Share값 계산의 결과 획득 가능한 대역이 Limit에서 제한하고 있는 값보다 큰 경우 Limit의 값이 적용된다.

Load Based Teaming

LBT는 복수의 물리 NIC을 통합 가능한 대역의 확보와 이중화를 제공하는 “NIC Teamng”이 적용된다. 복수의 물리 NIC으로 Link을 구성함과 더불어 각 Traffic이 어떻게 물리 NIC을 결정하는 가의 알고리즘이 필요하게 된다. 해당 알고리즘은 아래와 같다.

  1. Port ID Based
    Default로 이용되는 알고리즘으로 Port ID란 가상 Switch내의 Port ID. 가상 NIC이 접속하고 있는 가상 Port별로 이용하는 물리 NIC이 결정 된다. 즉, 하나의 가상 NIC을 하나의 물리 NIC을 대응하는 방식이지만, 복수의 가상 Machine인 환경에선 부하 분산도 기대 할 수 있다.
  2. Source MAC
    Traffic의 Source측의 MAC Address, 말하자면 가상 NIC의 MAC Address 정보를 기초로 한 Hash값을 두고 물리 NIC을 결정하는 알고리즘. 하나의 가상 NIC이 최종적으로 하나의 물리 NIC을 댕응하는 점에서는 Port ID Based와 같다.  많은 경우 Port ID Based의 부하분산은 유효하지만, 운영하는 형태에 따라서는 물리 NIC의 사용률이 균일하지 않은 경우가 있다. 예를 들면 물리 NIC x 2로 Teaming된 가상 Switch에 20대의 가상 Machine이 접속되어 있는 상황을 가정하면  System 운영 특성 상 홀수번째의 가상 Machine이 Active로 동작하고, 짝수번째의 가상 Machine은 대기하고 있다면, 이 경우 부하분산 알고리즘으로 Port ID Based를 이용하면 결과적으로 한쪽의 물리 NIC에 Traffic이 집중되어 버린다. 이런 경우 Source MAC을 이용하여 양측의 물리NC이 균일하게 사용되도록 할 수 있다.
  3. IP Hash
    IP Hash는 각 Traffic의 Source IP Address, Destination IP Address들을 바탕으로 Hash값을 계산하고, 이용하는 물리 NIC을 결정한다. 복수의 Destniation이 있는 경우, 하나의 가상 NIC이 복수의 물리 NIC을 사용 할 때 유리하다. IP Hash를 사용할 때는 물리 Switch측에 IEEE 802.3ad Link Aggregation을 유효화 시킬 필요가 있다.
  4. Load Based
    물리 NIC의 대역 사용 상황에 따라, 동적인 가상 Port와 물리 NIC간의 관계를 변경 한다. 초기 배치는 Port ID Based와 같은 방식으로 구성되지만, 운영 중 부하의 쏠림이 발생할 것 같으면 자동적으로 이 Mapping 을 변경 한다. vSphere 4.1로 부터 제공되는 기능으로 분산가상 Swtch만 지원 한다.

Load Based Teaming의 동작

LBT를 선택하면, 물리 NIC의 부하상황에 맞춰 가상 Port와 물리 NIC의 Mapping을 자동적으로 변경하게 된다. 이 때의 판단 기준은 Default로는 “물리 NIC의 대역 사용률이 75%를 넘는 경우가 30초이상 지속적으로 발생 할 때” .  Network Traffic은 순간적인 것, 지속적인 것이 있는데, 너무 과민하게 설정을 할 경우 오히려 역효과가 날 수 있다.

Network I/O Control, Load Based Teamin은 Enterprise Plus License가 필요하다.  쩝.. 슬픈 일이군..

Advertisement

Tech #3 : What is the Virtualization Technology?

(2007년 3월 1일)

“Server의 가상화”는 기업에 있어 이미 필수 기술이 되었다고 해도 과언이 아니다. 가상화에 있어 처리능력의 증강을 원한다면, 새로운 H/W를 구입할 필요는 없다. 그것은 말하자면, H/W구입비라고 하는 지출을 줄이는 것이기도 하고, Data Center의 Space와 전기 및 냉각에 드는 Cost를 절약하는 것이기도 하다. 물리적인 Server가 아닌 가상 Server를 선택하는 것은 기업에게 재무의 건전성을 부여하고, IT지출을 삭감하는 효과가 있다라고 하는 것이다. 여기에서 그런 Merit를 가진 가상화 Architecture 면으로부터 다시금 정리 해 보았다.

Nill Macarista
InforWorld Online 미국판

가상화의 기술, 가상화라는 Concept자체는 결코 새로운 것이 아니다. 실제, 이미 1970년대에 Main Frame Computer는 복수의 OS Instance를 동시에 실행하고 있었따. 그것이 가상화의 시작이 된다. 그 후, S/W와 H/W가 진화하여, 가상화는 더욱 가깝게 체감할 수 있는 기술이 되었다. 현재, 업계표준이 되어 있을 정도로 일반적인 Server에서도 가상화를 행하는 것이 가능하다.

지금, 시장에서는 proprietary로부터 Open Source까지, Data Center Manager가 선택하기 곤란할 정도로 많은 종류의 가상화 Solution이 넘쳐나고 있다. 여기서는 가상화에 대한 Approach 방법(Achitecture)에 있어 “완전 가상화” “모의 가상화” “OS Level의 가상화”의 3가지로 분류하고, 각각의 기술적인 특징을 소개한다.

※ Proprietary란,“전용의” “독자의” “독점적인” “소유권, 점유권이 있는” “비공개의”의 이미로, Computer관련용어로서는 Open의 Opposite word이다.
표준화가 진행된 PC (Client / Server System, Web System)에 따라 System을 “Open System”이라고 부를 때, Main Frame System과 같은 특정 Maker등에 따른 특정의 독자사양으로 구성된 Computer System을 “Proprietary System”이라고 한다.
또, Linux에 대표되는 Source Code가 공개된 S/W를 “Open Source Software” “Free Software”라고 부르는 것에 반해, Windows나 MAC OS와 같은 Software Maker가 Source Code(지적소유권)을 독점 소위 점유하고 있는 Soft는 “Proprietary Soft”라고 불린다.

완전 가상화 (Full Virtualization)
가상화 Solution 중에 가장 많이 보급된 것이 “Hipervisor”라고 불리우는 Architecture를 사용한 “완전 가상화”이다. 이것은 가상 Server와 H/W간에 추상적인 Layer(가상화 Layer를 실장한 전용 Kernel)을 배치하는 Architecture이다.
이 Approach를 채용하고 있는 상용제품으로는 “WMware”와 Micro Soft의 “Virtual PC”가 있고, Linux용 Open Source 제품으로는 “KVM (Kernel-based Virtual Machine)”가 있다.
Hipervivor는 CPU명령에 관여하여, H/W Controller와 주변기기로의 Access를 중개한다. 사실상, 어떤 OS라도 수정없이 가상 Server상에 Install할 수 있고, 그 Guest OS는 가상환경에 있다는 인식없이 가동한다. 더불어 이 Architecture의 결점은 Hipervivor에 의해 Processor에 큰 Overhead가 걸리는 것이다.
완전 가상화 환경에 있어 Hipervivor는 H/W상에서 직접 가동하고, Host OS(Kernel)로서 기능(다른 말로 하자면, Windows나 Linux 같은 일반 Host OS를 필요로하지 않음)한다. 그 Hipervivor가 관리하는 가상 Server상에서 Guest OS가 움직이는 셈이다.

 

모의 가상화 (Para Vritualization)
완전 가상화에서는 여러가지 가상 Server를 관리하고, 나아가 각각을 독립 가동시키고 있는 Hipervivor의 요구가 모든 Processor에 집약(그 때, Guest OS는 일절 가상화에는 관여하지 않음)된다.
이 부담을 경감시키기위한 수단의 한가지가 Guest OS에 관여 가상화 환경을 인식시키도록 함과 더불어 Hipervivor와 연계시키는 것이다. 이것이 “모의 가상화”라고 불리는 Approach이다.
이 모의 가상화 방식을 채용하고 있는 대표적인 제품이 Open Source “Xen”이다. Xen에서는 Kernel부분에 변경을 가함으로서 처음으로 Xen Hipervivor의 가상 Server상에서 Guest OS가 가동가능하게 된다. 이로 인해 BSD, Linux, Solaris와 같은 Open Source OS는 Support하지만, 수정을 할 수 없는 Windows등의 Proprietary System의 가상화에는 적합하지 않다.
모의 가상화의 우위성은 “Performance”에 있다. Hipervivor와 연계하는 모의 가상화 Server는 가상화되고 있지 않은 Server와 거의 동등한 성능을 발휘한다. Micro Soft와 VMware가 각각 자사제품을 보완하기 위해 모의 가상화기술에 힘을 쏟고 있는 상황을 보면, 그것이 충분히 매력적인 기술이라는 것을 알려주는 것이다.

 

OS Level의 가상화 (OS Level Virtualization)
OS Level의 가상화로는 문자그 의미대로 OS(Host OS)의 기능에 의해 가상화를 실현하는 Architecture가 있다. Hipervivor Layer는 존재하지 않고, Host OS가 스스로 H/W Resource를 분할 하거나, 각 Server를 독립 운영시키거나 한다. 모든 가상 Server가 동일 OS상에서 가동하는 점이, 다른 가상화 기술과의 큰 차이(그러나, 각 Instance는 고유의 Application과 User Account를 보유함)이다.
이 Architecture의 결점은 “유연성”이 결여되어 있는 것이지만, 그 반면 “Native Speed 향상이 가능하다”라는 이점도 있다. 또, 모든 가상 Server에 단일 표준의 OS가 적용되어지기 때문에, 다른 환경에 비해서 관리가 용이하다는 점도 Merit로 여겨진다.

CPU의 가상화 대응
Main Frame과는 다르게 PC의 H/W는 원래 가상화를 고려하여 설계되었다고 말 할 수 없다. 그로인해 최근까지 부하는 모든 S/W에 걸리지만, AMD와 Intel이 최신세대 Processor에서 처음으로 CPU Level에의 가상화를 Support하기 시작한 걸로 인해, 상황은 크게 바뀌려고 하고 있다.
더불어, AMD와 Intel의 Technology는 동일한 Merit를 가지고 있지만, 불행하게도 Code의 호환성은 없다.
그렇다하더라고, H/W Level의 가상화 Support로 인해, 가상 Server로부터 I/O Channel이나 H/W Resource로의 Access관리는 H/W측에서 행해지게 되고, Hipervivor가 부담해 오던 관리부하는 상당히 경감되었다. 또, OS(Windows를 포함)에 관여하지 않고도, 모의 가상화 환경으로 가동시킬 수 있게 되었다.
더욱이, CPU Level의 가상화 환경을 실현하기 위해서는 가상화 S/W를 다시 만들어야 하는 절차가 필요하다고 한다. 그러면서도, 이 기술이 가져다 주는 Merit는 그 부분을 고려하고도 남을 정도로 크기 때문에, 결국 이런 저런 종류의 가상화 S/W가 이 기술을 Support하게 될 것이다.

각각의 기술의 비교
지금까지 소개했던 가상화 방법 중 어느것을 채용할지는 각각의 기업(Data Center)이 놓여있는 상황에 따라 다를 것이다. 예로, 단일 OS Platform을 기반으로 하는 Server군의 경우에는 OS Level의 가상화로 통합하는 방법이 적합하다고 말 할 수 있다.
한편, 모의 가상화 방법을 채용하면 – 특히 가상화에 대응하는 Processor와의 연계가 완성되어 있는 경우에는 – 높은 성능을 유지하면서, 다른 종류의 Guest OS System 환경이 구축가능한 Merit를 흡수하는 것이 가능하다.
또, 완전 가상화는 3가지의 가상화 방법 중 성능면에서는 가장 떨어지지만, Guest OS간의 완전한 독립성을 유지할 수 있는 Merit를 가진다. 많은(종류의) Guest OS를 Support하고 싶을 때, 소위 S/W 품질보증이나 Test를 행하고 싶을 때에는 이 방법이 적합하다고 할 수 있다.
완전 가상화 Solution은 그 외에도 여러가지 특징이 있다. 예로, 가상 Server의 특정시점에서의 상태 정보를 취득하고, 보존해 두는 “Snapshot”기능을 이용하면, 여지껏 간단하게 장애복구 대책을 실시 할 수 있다. 또, 최근에 이 기능을 활요하여, 자사제품의 평가판을 Pre-Package화한 가상 Server Image로서 Download 제공하고 있는 S/W 기업도 증가하고 있다.
그렇다하더라도, 가상화 기술/Architecture를 막론하고, 가상 Server에는 물리 Server라는 지금까지와 같은, 계속적인 Support와 Maintenance를 필요로 한다. 이미, 기존의 IT환경으로부터 효율적인 Cost 효과에 우수한 가상화 환경으로의 이행을 간단하게 행하기 위한 Tool을 시작, 여러가지 가상 Server 용 관리제품이 시장에 투입되고 있기 때문에, 그것들을 활용하면서 보다 좋은 가상화 환경의 실현 해 나갈 수 있다.

 

※ 위 글은 아래의 링크의 기사를 번역한 글입니다. 다소 오역이 있을 수 있습니다.

http://www.computerworld.jp/topics/vt/59310-1.html

Tech #2 : What is the x64?

그냥 지나치고 넘어 갈 수도 있는 CPU 관련 내용을 재 정리 해 봅니다.

우선, x64란?

 32bit Architecture(IA-32)를 64bit로 확장시킨 Architecture, 또는 그것과 호환성이 있는 기술의 총칭.

Intel은 자사 Architecture를 “EM64T(Intel Extended Memory 64 Technology”라고 하고, AMD(Advanced Micro Devices, Inc.)는 “AMD64 ISA”라고 하고 있습니다. x64 대응 Processor를 개발하고 있는 건 위의 Intel과 AMD입니다.

 x64의 설계는 기존 32bit Architecture의 진화의 연장선상에 있고, x64는 차세대 Computing으로의 벽을 부수고, 과거의 자산을 활용하는 방법을 제공하고 있습니다. 즉, x64는 새로운 64bit Solution을 도입가능하도록 함과 동시에 기존의 32bit Solution에 대한 지금까지의 투자를 보완하기 위한 개념에서 탄생된 새로운 형태의 Technology입니다.

64bit Technology가 필요한 이유

 64bit 환경을 필요로 하고 있는 것은 고성능을 필요로하는 대용량 물리 Memory와 가상 Memory를 사용하는 Application. 32bit로 관리 가능한 Addressing Area는 근본적으로 4GB까지 제한되어 버리고, 또, 많은 32bit OS가 Address 가능한 영역도 2GB까지 제한하여 이이상의 Memory영역을 사용하고 싶은 Computing 기능의 강화를 필요로하는 User는 64bit 환경으로 전환해야만 할 필요성이 있죠. 그로 인해 기존 자산인 32bit 환경을 어떻게 해야 할지 하는 문제가 발생합니다.

 AMD64와 EM64T의 64bit Technology에 의해 일부 또는 모든 Application의 Software, Hardware를 32bit에서 64bit로 서서히 전환 가능하게 되었습니다.

AMD와 AMD64

 AMD는 오래전부터 Intel 호환 Processor 개발을 했던 America의 Maker. 회사의 기술 Level은 상당히 높았고, Original의 x86계 Processor 개발 Maker였던 Intel을 놀라게 할 정도의 존재 가치가 되어 가고 있습니다. 그 대표적인 기술이 AMD64 Platform. AMD64는 IA-32등에서 사용되었던 x86 명령 Set을 확장, 64bit Platform로, Intel의 EMT64에 앞서, 기존 x86 Solution과의 완전호환성을 가지면서, 64bit 성능을 제공하도록 설계되어 있습니다.

 2003년 4월, Server 혹은 Workstation 용의 AMD Opteron Processor가 등장. 더불어 AMD는 처음으로 Windows 대응 Desktop/Mobile Processor인 AMD Athlon 64 Processor를 2003년 9월에 발표했습니다. 이 때 Code Name “Hammer”라고 했던 AMD64는 2005년엔 “AMD64 Platform”으로, “x86-64″라는 64bit 확장 기능에 대해서 “AMD64 ISA” (AMD 64 Inform Set Architecture)라고 하게 되었습니다.

Intel과 EM64T

 Intel은 업계 최고의 America 최대의 Processor Maker. Intel은 차세대 Processor로서, Hi-end 64bit 전용 Processor인 Itanium/Itanium2를 개발하고 있었지만, Itanium2는 기존 32bit Architecture와는 Hardware Level의 호환성이 없었습니다.

 그 때 Rival 기업인 AMD가 “기존 32bit Architecture에 64bit 기능을 추가한다”라는 새로운 전략을 내세웠기 때문에, 그것에 대항하기 위해 EM64T라는 AMD의 AMD64와 동등한 호환성의 높은 시술을 발표했습니다. 물론, Intel도 기존의 32bit Architecture에 64bit 확장기능을 추가하는 것을 전부터 연구하고 있었습니다. 그러나, 준비가 되기도 전에 AMD가 선수를 치는 형식이 되고, 결과적으로 Intel의 EM64T는 AMD보다 한발 늦게 시장에 투입되게 되었습니다.

 2004년 2월, Intel은 Dual Processor Server/Workstation 용으로 Intel Xeon Processor 개발 Code Name “Nocona” 또는 “Potomac” (Xeon MP Processor 개발 Code Name), 그리고, Single Processor “Prescott” 위 3개의 IA-32 Processor에 Intel EM64T를 탑재한다고 발표했습니다.

 EM64T의 기술은 Pentium4 또는 Xeon Processor (6xx Sequence의 Pentium4 Processor)부터 탑재되기 시작했습니다.

x64 기술의 Merit

 기존 x86환경, 또는 64bit 전용의 환경보다 x86환경에서 잘 동작하는 Application 혹은 Case Study는 많이 있습니다. 64bit Native Code로 해도 이점이 없는 Application에 대해서는 변환작업이 필요없고, 그 대로 x64 환경에서도 성능을 Full로 발휘 가능합니다. 특히, Modeling Simulation, 통계, 재무분석, 화상, Video, 신호처리, 물리학, 의학연구, Telecom, 암호화, 압축등 수학적정산과 부동소수점연산기능을 필요로하는 Application에 유리합니다. 게다가,의사결정지원, 검색, 색인, Document, Contents관리, 음성인식등, 대용량 및 고성능의 Database기능을 필요로하는 Application을 비롯, Computer 지원 설계, 제조, Engineering(CAD, CAM, CAE), Digital 음악제작 혹은 Video 편집, Digital Contents 작성, Realtime Media Streaming Solution등의 Application에도 유리하게 적용됩니다.

Tech #1 : What is the 64bit?

Processor PC의 세계는 4bit 시대로부터 시작하여, Z80에 대표되는 8bit, 8086과 MPU68000에 대표되는 16bit, i386과 Pentium에 대표되는 32bit로 발전되어 왔다.  그리고, 64bit 시대에 접어들어 “64bit화”가 진행되고 있다.

64bit란?

 간단하게 말하자면, Bit(1또는 0인 Computer의 최소단위)의 수가 64개가 나열되어 있는 것. 이 64개의 1과 0을 조합하여 표현 가능한 수의 폭은 264 이 됩니다.  각 bit수와 값을 Table 1로 정리하면.

Table 1 Bit수와 값의 범위
Bit수 값의 범위(Addressing의 범위) Size
4bit 24 0 ~ 16[0xF] 16byte
8bit 28 -128 ~ +127
0 ~ 255[0xFF]
256byte
16bit 216 -32768 ~ +32767
0 ~ 65535[0xFFFF]
64Kbyte
32bit 232 -2147483648 ~ 2147483647
0 ~ 4294967295[0xFFFFFFFF]
4Gbyte
64bit 264 -9223372036854775808 ~ 9223372036854775807
0 ~ 18446744073709551615[0xFFFFFFFFFFFFFFFF]
16Ebyte

 

 이 값의 범위를 비교해 보면, 64bit라는 수가 엄청난 크기의 값이라는 걸 금방 알 수 있을 겁니다. 64bit에서 표현가능한 Address 범위는 16Ebyte나 됩니다. 참고로 Ebyte를 참고하기 위해 아래 표를 확인.

Table 2 값의 단위와 Binary 값
단위 Binary 값
Kilo(K) 1,000 1,024
Mega(M) 1,000,000 1,048,576
Giga(G) 1,000,000,000 1,073,741,824
Tera(T) 1,000,000,000,000 1,099,511,627,776
Peta(P) 1,000,000,000,000,000 1,125,899,906,842,624
Exa(E) 1,000,000,000,000,000,000 1,152,921,504,606,846,976

 

물리 Address와 가상 Address의 범위

 위에서 64bi의 Address범위는 16EByte라고 설명했지만, 현재의 64bit 대응 Processor으로는 모든 Address범위를 다루지 못 합니다.

 Itanium2 Processor로 대표되는 Intel IA-64 Architecture에서는 50bit가 물리 Address 범위입니다. 또, AMD Opteron등의 AMD64 Architecture에서는 40bit까지의 물리 Address와 48bit까지의 가상 Address가 Support되고 있습니다. 이 40bit라는 값은 1TByte까지의 물리 Address범위를 cover하고 있는 것이 됩니다.

 또, 이 범위에 관해서는 Processor 혹은 OS 종류에 따라 달라지기 때문에 주의 할 필요가 있습니다. 실제의 64bit 대응 Processor에서 다룰 수 있는 물리 Address 범위는 Table 3에 있습니다.

Table 3 주요 64bit 대응 Processor의 물리 Address 범위
Processor Architecture 물리Address 가상Address
Intel Itanium2 IA-64 50bit 64bit
Intel Itanium IA-64 44bit 54bit
AMD Opteron AMD64 40bit 48bit
AMD Athlon 64 AMD64 40bit 48bit

 

왜 64bit를 필요로하는가?

 Computer 세대가 발전에 나가는 것에 맞춰, bit수도 증가해 왔습니다. 그럼, 왜 이와같이 bit수를 증가시켜야만 했을까요. 그것은 기술의 발달과 함께 처리해야하는 Data량이 증가하여, Computer에 실장되어 있는 Memory의 상한선에 다다르게 되었기 때문입니다.

 이미 Memory는 32bit의 한계범위에 있는 4GByte(232 Byte)에 도달 해 버렸습니다. 일반적인 32bit Computer에서 4GByte 이상의 Memory를 직접(물리적으로) Access 접근할 수 없습니다. 그러나, Hi-End의 x86 Multiple Processor System에서는 이미 이 4GByte의 폭을 넘어서 있습니다.

 Intel Server용의 Xeon Processor (Nocona 혹은 일부의 Prescott Core)에서는 “Intel Extended Server Memory Architecture”라고 하는 확장 기능으로 36bit의 물리 Address 공간을 Support하고 있고, 최대 64GByte까지의 Memory 영역을 다룰 수 있습니다. 그러나, 이것은 물리 Address의 한계로의 근본적인 해결책은 아닙니다.

 이런 문제를 해결하기 위해서, 64bit로 가기위한 준비의 필요성이 부각되고 있습니다.

64bit는 32bit의 배

 64bit는 32bit의 배의 bit폭이므로, 처리속도 및 다룰 수 있는 Data양도 배가 된다고 기대하기 쉽지만, 그렇지 않습니다. 이런 잘못된 인식을 갖지 않도록 64bit에 대해서 정확하게 이해하고 있지않으면 안되지요.