HW 엔지니어를 위한 Deep Learning

2023년 4월 10일 월요일

NPU와 GPU의 차이점에 대한 문답

Q1. NPU와 GPU의 차이점을 알려주세요.

A1. NPU와 GPU는 둘 다 특정 유형의 계산을 위해 설계된 특수 프로세서 유형입니다. NPU는 Neural Processing Unit의 약자이고 GPU는 Graphics Processing Unit의 약자입니다. 두 가지 주요 차이점은 다음과 같습니다.

기능: GPU는 주로 그래픽 처리 및 렌더링용으로 설계된 반면 NPU는 딥 러닝 워크로드를 가속화하기 위해 특별히 설계되었습니다.

아키텍처: GPU에는 일반적으로 다양한 유형의 계산에 사용할 수 있는 더 많은 범용 처리 장치가 있으며 NPU는 딥 러닝 알고리즘의 핵심 작업인 행렬 곱셈에 최적화되어 있습니다.

메모리: GPU는 일반적으로 NPU보다 메모리 용량과 대역폭이 더 큽니다. 이는 많은 양의 데이터를 빠르게 처리해야 하는 특정 유형의 애플리케이션에 중요할 수 있습니다.

전력 효율성: NPU는 딥 러닝 워크로드가 계산 집약적일 수 있고 많은 에너지가 필요할 수 있으므로 GPU보다 전력 효율적으로 설계되었습니다.

소프트웨어 호환성: GPU는 훨씬 더 오래 사용되어 왔으며 더 성숙한 소프트웨어 생태계를 가지고 있는 반면, NPU는 여전히 상대적으로 새롭고 소프트웨어 지원이 제한적일 수 있습니다.

전반적으로 NPU와 GPU의 주요 차이점은 NPU는 딥 러닝 워크로드를 가속화하도록 특별히 설계된 반면 GPU는 그래픽 처리 및 기타 다양한 작업에 적합한 범용 프로세서라는 것입니다.

Q2. GPU에서 범용 처리 장치의 사용 사례에 대한 몇 가지 예를 알려주십시오. CUDA 코어가 범용 처리 장치로도 설명될 수 있다는 것을 몰랐습니다.

A2. 확신하는! GPU는 주로 그래픽 처리 및 렌더링에 사용되는 것으로 알려져 있지만 고성능 컴퓨팅이 필요한 다양한 기타 응용 프로그램에도 사용됩니다. 다음은 몇 가지 예입니다.

기계 학습: GPU는 일반적으로 기계 학습 모델의 학습 및 추론을 가속화하는 데 사용됩니다. 대량의 데이터를 처리하고 기존 CPU보다 훨씬 빠르게 신경망에 필요한 행렬 곱셈 및 기타 작업을 수행할 수 있습니다.

과학적 시뮬레이션: GPU는 물리학, 화학, 생물학과 같은 과학 분야에서 시뮬레이션을 가속화하는 데 사용됩니다. 복잡한 물리적 시스템을 시뮬레이션하고 CPU보다 훨씬 효율적으로 대규모 계산을 수행하는 데 사용할 수 있습니다.

암호화폐 채굴: GPU는 채굴 알고리즘에 필요한 복잡한 계산을 수행하여 암호화폐를 채굴하는 데 사용됩니다. Ethereum, Bitcoin 및 Litecoin을 포함한 다양한 암호 화폐를 채굴하는 데 사용할 수 있습니다.

비디오 인코딩: GPU는 매우 계산 집약적인 비디오 인코딩 및 디코딩을 가속화하는 데 사용됩니다. 많은 양의 비디오 데이터를 처리하고 CPU보다 훨씬 빠르게 처리할 수 있습니다.

게임: 물론 GPU는 게임에도 사용됩니다! 고품질 그래픽을 렌더링하고 최신 비디오 게임에서 원활한 게임 플레이를 가능하게 하는 일을 담당합니다.

두 번째 질문과 관련하여 CUDA 코어는 실제로 그래픽 처리를 넘어 광범위한 작업에 사용할 수 있는 범용 처리 장치입니다. 병렬 처리 작업을 가속화하도록 특별히 설계되었으며 다양한 계산을 수행하도록 프로그래밍할 수 있습니다. 실제로 CUDA 프로그래밍 언어 및 툴킷은 기계 학습, 과학 시뮬레이션 및 비디오 처리와 같은 작업에 널리 사용됩니다.

Q3. NPU의 제한된 소프트웨어 생태계에 대해 자세히 알려주십시오. 그렇다면 tensorflow 또는 pytorch와 같은 잘 알려진 프레임워크가 NPU를 지원하지 않는 경우 NPU는 기계 학습에 어떻게 사용됩니까?

A3. NPU는 여전히 상대적으로 새로운 기술이므로 NPU의 소프트웨어 생태계는 GPU만큼 성숙하지 않습니다. TensorFlow, PyTorch 및 MXNet과 같은 인기 있는 기계 학습 프레임워크는 기본적으로 NPU를 지원하지 않지만 NPU를 기계 학습에 사용할 수 있는 몇 가지 방법이 있습니다.

공급업체별 라이브러리: Huawei 및 Cambricon과 같은 일부 NPU 공급업체는 해당 NPU에 최적화된 자체 기계 학습 라이브러리를 개발했습니다. 이러한 라이브러리는 공급업체의 NPU에서 실행할 수 있는 기계 학습 모델을 작성하는 데 사용할 수 있습니다.

컴파일러 기반 최적화: 컴파일러 기반 최적화 도구를 사용하여 머신 러닝 모델을 자동으로 최적화하여 NPU에서 실행할 수 있습니다. 이러한 도구는 모델을 분석하고 NPU의 특정 아키텍처에 최적화된 코드를 생성할 수 있습니다.

프레임워크 확장: TensorFlow 및 PyTorch와 같은 일부 기계 학습 프레임워크에는 NPU에서 실행할 수 있는 확장이 있습니다. 이러한 확장은 이러한 프레임워크의 친숙한 API를 사용하여 기계 학습 모델을 작성하는 동시에 NPU 가속의 이점을 계속 활용할 수 있는 방법을 제공합니다.

NPU 지원 프레임워크로 모델 포팅: 또 다른 옵션은 기계 학습 모델을 NPU를 지원하는 프레임워크로 포팅하는 것입니다. 예를 들어 TensorFlow로 작성된 모델은 Huawei에서 개발한 MindSpore와 같은 NPU 지원 프레임워크로 내보낼 수 있습니다.

NPU를 위한 제한된 소프트웨어 에코시스템으로 인해 머신 러닝에 NPU를 사용하는 것이 어려울 수 있지만 NPU를 머신 러닝 워크플로에 통합할 수 있는 몇 가지 방법이 여전히 있습니다. NPU의 사용이 보다 널리 보급됨에 따라 더 많은 소프트웨어 지원이 제공될 가능성이 높습니다.

Q4. 일반적으로 NPU는 서버에 어떻게 연결됩니까? PCIe 버스 또는 특수 커넥터 기술을 통해 연결됩니까?

A4. 일반적으로 NPU는 고속 직렬 컴퓨터 확장 버스 표준인 PCIe(Peripheral Component Interconnect Express) 인터페이스를 사용하여 서버에 연결됩니다. NPU는 일반적으로 서버 마더보드의 사용 가능한 PCIe 슬롯에 연결되는 확장 카드로 설치됩니다. PCIe 인터페이스는 NPU와 서버의 CPU 및 메모리 간에 고속 데이터 전송을 제공합니다.

일부 공급업체는 특수 커넥터 또는 상호 연결과 같은 NPU에 대한 다른 인터페이스 옵션도 제공할 수 있지만 PCIe는 NPU를 서버에 연결하기 위한 가장 일반적이고 널리 지원되는 인터페이스입니다. PCIe 인터페이스는 NPU에서 처리해야 하는 대량의 데이터에 적합한 고대역폭, 저지연 연결을 제공합니다.

서버에 연결되면 NPU를 사용하여 서버의 CPU에서 특정 유형의 계산을 오프로드하여 CPU가 다른 작업을 수행할 수 있도록 할 수 있습니다. 이는 많은 계산이 필요한 기계 학습 또는 데이터 분석과 같은 특정 유형의 워크로드를 가속화하는 데 도움이 될 수 있습니다.

Q5. 10개의 NPU 공급업체와 그들의 NPU 제품을 인기순으로 나열할 수 있습니까? 목록에서 GPU 공급업체를 제외하세요.

A5. 물론입니다. GPU 공급업체를 제외하는 목록은 다음과 같습니다.

Google: Google의 TPU(Tensor Processing Unit)는 딥 러닝 워크로드에 사용하도록 설계되었습니다. 최신 제품인 TPU v4는 교육 및 추론 워크로드를 위해 설계되었습니다.

Intel: Intel의 Nervana 신경망 프로세서(NNP)는 딥 러닝 워크로드에 사용하도록 설계되었습니다. 최신 제품인 NNP-T1000은 교육용으로 설계되었으며 NNP-I1000은 추론용으로 설계되었습니다.

Qualcomm: Qualcomm의 AI 엔진에는 딥 러닝을 포함한 기계 학습 워크로드를 실행하기 위한 하드웨어 가속기가 포함되어 있습니다. 최신 제품인 AI Engine 880은 모바일 장치용으로 설계되었습니다.

Huawei: Huawei의 NPU Ascend 시리즈에는 기계 학습 워크로드를 실행하기 위한 하드웨어가 포함되어 있습니다. 최신 제품인 Ascend 910은 데이터 센터 및 클라우드 컴퓨팅에서 사용하도록 설계되었습니다.

Amazon: Amazon의 Inferentia는 클라우드 컴퓨팅 환경에서 사용하도록 설계된 NPU입니다. 최신 제품인 Inferentia 2는 기계 학습 및 추론 워크로드를 실행하도록 설계되었습니다.

Xilinx: Xilinx의 Alveo 가속기 카드 시리즈에는 기계 학습 및 데이터 분석을 위한 하드웨어가 포함되어 있습니다. 최신 제품인 Alveo U50은 데이터 센터 및 클라우드 컴퓨팅 환경에서 워크로드를 가속화하도록 설계되었습니다.

Habana Labs: Habana Labs는 Gaudi 및 Goya를 비롯한 여러 NPU 제품을 생산하는 이스라엘 회사입니다. 이러한 NPU는 클라우드 컴퓨팅, 데이터 센터 및 에지 컴퓨팅에서 사용하도록 설계되었습니다.

Cambricon: Cambricon은 Cambricon 1M, Cambricon 1H 및 Cambricon 1H2를 비롯한 여러 NPU 제품을 생산하는 중국 회사입니다. 이러한 NPU는 클라우드 컴퓨팅, 데이터 센터 및 에지 컴퓨팅에서 사용하도록 설계되었습니다.

Graphcore: Graphcore의 IPU(Intelligence Processing Unit)는 딥 러닝 애플리케이션에 사용하도록 설계되었습니다. 최신 제품인 IPU-M2000은 교육 및 추론 워크로드 모두를 위해 설계되었습니다.

Tenstorrent: Tenstorrent의 Grayskull 아키텍처는 딥 러닝 및 머신 러닝 워크로드에 사용하도록 설계되었습니다. 최신 제품인 Tensix 칩은 훈련과 추론을 위해 설계되었습니다.

다시 말하지만, 인기도는 주관적일 수 있으며 특정 산업이나 사용 사례에 따라 달라질 수 있다는 점에 유의할 가치가 있습니다. 그럼에도 불구하고 이러한 NPU 공급업체와 해당 제품은 모두 업계의 핵심 업체로 인식되고 있습니다.

Q6. Habana Labs Gaudi에서 ML/DL에 어떤 종류의 소프트웨어 환경을 사용할 수 있습니까?

A6. Habana Labs Gaudi NPU는 ML/DL 워크로드를 위한 다양한 소프트웨어 환경에서 작동하도록 설계되었습니다. 여기 몇 가지 예가 있어요.

TensorFlow: Habana Labs는 Gaudi에서 실행하도록 최적화된 TensorFlow-Habana라는 맞춤형 TensorFlow 배포판을 제공합니다. 이 배포판에는 컨볼루션 및 순환 신경망과 같은 널리 사용되는 ML/DL 작업에 대한 지원이 포함되며 Gaudi의 아키텍처를 최대한 활용하도록 설계되었습니다.

PyTorch: Gaudi는 인기 있는 오픈 소스 ML/DL 프레임워크인 PyTorch도 지원합니다. Habana Labs는 Gaudi에 최적화된 HabanaPytorch라는 맞춤형 PyTorch 확장 기능을 제공하며 회선 및 배치 정규화와 같은 널리 사용되는 작업에 대한 지원을 포함합니다.

ONNX: Gaudi는 ML/DL 모델을 나타내는 개방형 표준인 ONNX(Open Neural Network Exchange) 형식도 지원합니다. ONNX 모델은 Gaudi로 가져와 고성능으로 실행할 수 있습니다.

Habana SynapseAI: Habana Labs는 SynapseAI라는 자체 소프트웨어 개발 키트도 제공합니다. 여기에는 ML/DL 개발자를 위한 고급 API 세트가 포함되어 있습니다. 이러한 API를 통해 개발자는 Gaudi에서 모델을 쉽게 생성, 교육 및 배포하고 NPU의 전체 기능을 활용할 수 있습니다.

전반적으로 Habana Labs는 개발자가 Gaudi NPU의 성능과 기능을 쉽게 활용할 수 있도록 설계된 다양한 소프트웨어 도구와 API를 제공합니다.

Q7. Habana Labs Gaudi는 어떤 OS에서 지원되나요?

A7. Habana Labs Gaudi NPU는 다음을 포함한 여러 운영 체제에서 지원됩니다.

Ubuntu: Habana Labs는 Ubuntu 18.04 및 20.04 LTS에서 Gaudi용 드라이버, 라이브러리 및 소프트웨어 패키지를 제공합니다. 이러한 패키지는 시스템의 패키지 소스에 추가할 수 있는 Habana Labs APT 저장소를 통해 사용할 수 있습니다.

RHEL(Red Hat Enterprise Linux): Habana Labs는 RHEL 8.4에서 Gaudi용 드라이버 및 소프트웨어 패키지를 제공합니다. 이러한 패키지는 시스템의 패키지 소스에 추가할 수 있는 Habana Labs YUM 저장소를 통해 사용할 수 있습니다.

CentOS: Gaudi는 RHEL과 동일한 패키지 및 리포지토리를 사용하여 CentOS 8.4에서도 지원됩니다.

SUSE Linux Enterprise Server(SLES): Habana Labs는 SLES 15 SP3에서 Gaudi용 드라이버 및 소프트웨어 패키지를 제공합니다. 이러한 패키지는 Habana Labs SUSE 리포지토리를 통해 사용할 수 있습니다.

Gaudi를 사용하려면 시스템이 지원되는 CPU, 메모리 및 마더보드를 포함하여 특정 하드웨어 요구 사항을 충족해야 합니다. Habana Labs는 웹 사이트에서 Gaudi와 호환되는 인증 시스템 목록을 제공합니다.

2022년 12월 7일 수요일

Microsoft .NET 7, 이제 IBM Power에서도 지원

.NET 7이 이제 Linux on Power (ppc64le)에서도 지원됩니다. 즉 ppc64le 아키텍처의 Power 서버에서는 C# 언어도 지원하게 되었습니다. 이로써 microservices app 개발에 사용되는 5개 프로그래밍 언어가 모두 ppc64le에서 지원됩니다.

즉, 과거에는 Oracle 등 AIX에서 수행되는 기간계 시스템과 연계하여 C# 언어로 작성된 업무 프로그램을 사용하기 위해서는 Windows 또는 Linux를 설치한 x86 시스템이 필요했으나, 이제는 x86이 필요하지 않고 같은 Power 시스템에 설치된 Redhat 또는 Openshift container에서 C# 업무 프로그램을 운용할 수 있게 된 것입니다.

2021년 Stack Overflow에서의 개발자 설문에 따르면 .NET framework은 전업 개발자들에게 있어서 가장 중요한 프레임웍 및 라이브러리입니다.

관련 발표는 아래 URL에서 좀 더 자세히 보실 수 있습니다.

https://community.ibm.com/community/user/powerdeveloper/blogs/janani-janakiraman/2022/11/07/net7-support-linux-on-power

또한 .NET 7 ppc64le는 이미 고객 reference가 있습니다. 독일의 컴퓨터 설계 관련 기업인 SKM Informatik GmbH인데, 이 기업의 요청으로 .NET 7의 ppc64le 지원이 시작되었다고 합니다.

https://www.ibm.com/downloads/cas/29RYARBY

.NET 7은 github에 그 source code가 공개되니 직접 build 하셔도 됩니다만, .NET 7 for ppc64le는 Openshift container 이미지로 제공되고 또 RHEL 8.7 또는 RHEL 9.1에서 YUM repository를 통해서도 제공됩니다.

.NET 7 관련된 패키지들은 yum 명령어를 통해 패키지로 아래 예와 같이 설치하실 수 있습니다.

[cecuser@p1274-pvm1 ~]$ hostnamectl

Static hostname: p1274-pvm1

Icon name: computer-vm

Chassis: vm

Machine ID: e5e70adcd98c4b56b00cc49cbf093412

Boot ID: 36e5448112b5432c91f40abe413cb05a

Virtualization: powervm

Operating System: Red Hat Enterprise Linux 8.7 (Ootpa)

CPE OS Name: cpe:/o:redhat:enterprise_linux:8::baseos

Kernel: Linux 4.18.0-372.9.1.el8.ppc64le

Architecture: ppc64-le

[cecuser@p1274-pvm1 ~]$ yum list | grep dotnet

dotnet.ppc64le 7.0.100-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

dotnet-apphost-pack-7.0.ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

dotnet-host.ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

dotnet-hostfxr-7.0.ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

dotnet-runtime-7.0.ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

dotnet-sdk-7.0.ppc64le 7.0.100-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

dotnet-sdk-7.0-source-built-artifacts.ppc64le 7.0.100-1.el8_7 codeready-builder-for-rhel-8-ppc64le-rpms

dotnet-targeting-pack-7.0.ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

dotnet-templates-7.0.ppc64le 7.0.100-1.el8_7 rhel-8-for-ppc64le-appstream-rpms

[cecuser@p1274-pvm1 ~]$ sudo yum install dotnet-sdk-7.0

Updating Subscription Management repositories.

Last metadata expiration check: 23:10:11 ago on Tue 06 Dec 2022 03:10:01 AM EST.

Dependencies resolved.

===================================================================================================

Package Arch Version Repository Size

===================================================================================================

Installing:

dotnet-sdk-7.0 ppc64le 7.0.100-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 53 M

Installing dependencies:

aspnetcore-runtime-7.0 ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 2.8 M

aspnetcore-targeting-pack-7.0 ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 1.6 M

dotnet-apphost-pack-7.0 ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 100 k

dotnet-host ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 190 k

dotnet-hostfxr-7.0 ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 175 k

dotnet-runtime-7.0 ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 7.8 M

dotnet-targeting-pack-7.0 ppc64le 7.0.0-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 2.9 M

dotnet-templates-7.0 ppc64le 7.0.100-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 3.1 M

netstandard-targeting-pack-2.1 ppc64le 7.0.100-1.el8_7 rhel-8-for-ppc64le-appstream-rpms 1.5 M

Transaction Summary

===================================================================================================

Install 10 Packages

Total download size: 73 M

Installed size: 311 M

Is this ok [y/N]: y

...

Installed:

aspnetcore-runtime-7.0-7.0.0-1.el8_7.ppc64le

aspnetcore-targeting-pack-7.0-7.0.0-1.el8_7.ppc64le

dotnet-apphost-pack-7.0-7.0.0-1.el8_7.ppc64le

dotnet-host-7.0.0-1.el8_7.ppc64le

dotnet-hostfxr-7.0-7.0.0-1.el8_7.ppc64le

dotnet-runtime-7.0-7.0.0-1.el8_7.ppc64le

dotnet-sdk-7.0-7.0.100-1.el8_7.ppc64le

dotnet-targeting-pack-7.0-7.0.0-1.el8_7.ppc64le

dotnet-templates-7.0-7.0.100-1.el8_7.ppc64le

netstandard-targeting-pack-2.1-7.0.100-1.el8_7.ppc64le

Complete!

설치는 위와 같이 매우 간단합니다. 이제 "Hello, World!"를 프린트하는 샘플 프로그램을 돌려보도록 하겠습니다.

[cecuser@p1274-pvm1 ~]$ dotnet

Usage: dotnet [options]

Usage: dotnet [path-to-application]

Options:

-h|--help Display help.

--info Display .NET information.

--list-sdks Display the installed SDKs.

--list-runtimes Display the installed runtimes.

path-to-application:

The path to an application .dll file to execute.

[cecuser@p1274-pvm1 ~]$ dotnet new console -o MyApp -f net7.0

Welcome to .NET 7.0!

---------------------

SDK Version: 7.0.100

----------------

Installed an ASP.NET Core HTTPS development certificate.

To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).

Learn about HTTPS: https://aka.ms/dotnet-https

----------------

Write your first app: https://aka.ms/dotnet-hello-world

Find out what's new: https://aka.ms/dotnet-whats-new

Explore documentation: https://aka.ms/dotnet-docs

Report issues and find source on GitHub: https://github.com/dotnet/core

Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli

--------------------------------------------------------------------------------------

The template "Console App" was created successfully.

Processing post-creation actions...

Restoring /home/cecuser/MyApp/MyApp.csproj:

Determining projects to restore...

Restored /home/cecuser/MyApp/MyApp.csproj (in 200 ms).

Restore succeeded.

[cecuser@p1274-pvm1 ~]$ cd MyApp

[cecuser@p1274-pvm1 MyApp]$ ls -la

total 12

drwxrwxr-x. 3 cecuser cecuser 55 Dec 7 02:24 .

drwx------. 23 cecuser cecuser 4096 Dec 7 02:24 ..

-rw-rw-r--. 1 cecuser cecuser 239 Dec 7 02:24 MyApp.csproj

drwxrwxr-x. 2 cecuser cecuser 168 Dec 7 02:24 obj

-rw-rw-r--. 1 cecuser cecuser 103 Dec 7 02:24 Program.cs

[cecuser@p1274-pvm1 MyApp]$ cat Program.cs

// See https://aka.ms/new-console-template for more information

Console.WriteLine("Hello, World!");

[cecuser@p1274-pvm1 MyApp]$ dotnet run

Hello, World!

[cecuser@p1274-pvm1 MyApp]$ ls -ltr

total 8

-rw-rw-r--. 1 cecuser cecuser 239 Dec 7 02:24 MyApp.csproj

-rw-rw-r--. 1 cecuser cecuser 103 Dec 7 02:24 Program.cs

drwxrwxr-x. 3 cecuser cecuser 181 Dec 7 02:26 obj

drwxrwxr-x. 3 cecuser cecuser 19 Dec 7 02:26 bin

[cecuser@p1274-pvm1 MyApp]$ ls -ltr bin/Debug/net7.0

total 168

-rw-rw-r--. 1 cecuser cecuser 10828 Dec 7 02:26 MyApp.pdb

-rw-rw-r--. 1 cecuser cecuser 4608 Dec 7 02:26 MyApp.dll

-rwxr-xr-x. 1 cecuser cecuser 139488 Dec 7 02:26 MyApp

-rw-rw-r--. 1 cecuser cecuser 385 Dec 7 02:26 MyApp.deps.json

-rw-rw-r--. 1 cecuser cecuser 139 Dec 7 02:26 MyApp.runtimeconfig.json

[cecuser@p1274-pvm1 MyApp]$ ./bin/Debug/net7.0/MyApp

Hello, World!

다만 아래의 MS 홈페이지의 .NET download 사이트에서는 ppc64le 관련 패키지는 별도로 제공되지 않네요.

https://devblogs.microsoft.com/dotnet/announcing-dotnet-7/

2022년 12월 5일 월요일

Power 서버 LPAR에서 "Compatibility Mode"란 대체 무엇인가?

Processor compatibility mode란 신규 processor에서도 오래된 버전의 OS를 지원하기 위해 사용되는 mode로서, Power 서버에서 logical partition (LPAR)를 설정할 때 정하는 것입니다.

이걸 그냥 default로 설정하면 hypervisor가 해당 LPAR를 부팅할 때, 그 OS 버전에 알맞은 최적의 mode를 자동으로 선정합니다.

POWER10에서는 OS 버전에 따라 p8 mode부터 p10 mode까지 사용이 가능하며, mode에 따른 성능 차이는 대부분의 경우 미미합니다. 따라서, 크게 신경 쓰지 않고 그냥 default로 두시는 것을 권고드립니다.

Power10의 경우 지원되는 OS에는 AIX 7.1도 있지만, AIX 7.3 또는 AIX 7.2 TL5 이상이 권고됩니다. AIX 7.1도 TL5 이상일 경우 지원은 가능하지만, 물리적 I/O (NIC, HBA)를 사용할 수 없고 VIOS를 통한 가상 I/O만 사용이 가능하기 때문입니다.

Power10에서 AIX 7.3 + Power10 mode (Native mode)를 사용할 경우 AIX 7.2 + Power9 mode에 비해 더 얻을 수 있는 이익은 다음과 같습니다만, 192개 이상의 CPU core를 사용하는 경우가 아닌 이상 그 성능 차이는 크지 않습니다.

1. LPAR 하나당 최대 1920개의 logical CPU (AIX 7.2의 경우 최대 1536개)

2. Power10의 MMA (Matrix Multiply Assist) 엔진 지원 (인공지능 inference 업무에 사용)

3. Power10에 최적화된 memcpy 성능

Power10에서 AIX 7.2 + Power9 mode를 사용할 경우 LPAR 하나당 logical CPU 개수가 최대 1536개 (192 * 8) 로 제한됩니다. 이는 p9 시절 최대 확장성이 12-core * 16-socket = 192 core (SMT8) 였기 때문입니다.

XIVE (eXternal Interrupt Virtualization Engine)란 network 가상화의 최적화를 위한 기술입니다.

MMA (Matrix Multiply Assist)란 Power10에 탑재된 행렬 연산 엔진이며, 이는 인공지능 inference 업무에 사용됩니다.

P10 optimized memcpy를 쓸 경우 성능이 어느 정도 향상되는지에 대한 명확한 수치는 발표된 바가 없습니다.

2022년 3월 28일 월요일

AIX에서 ping의 속도를 msec 이하 단위로 측정하는 방법

AIX에서는 ping의 응답 시간을 msec로만 보여줍니다.

/ # ping 10.10.14.121

PING 10.10.14.121 (10.10.14.121): 56 data bytes

64 bytes from 10.10.14.121: icmp_seq=0 ttl=255 time=0 ms

64 bytes from 10.10.14.121: icmp_seq=1 ttl=255 time=0 ms

이를 msec 이하의 좀 더 세밀한 단위로 볼 수 있는 방법이 필요할 경우, 아래와 같이 tcpdump를 이용하시면 됩니다.

1) 먼저 창을 2개 띄우시고, 한쪽에서는 목적지 server로 ping을 수행합니다.

/ # ping 10.10.14.121

PING 10.10.14.121 (10.10.14.121): 56 data bytes

64 bytes from 10.10.14.121: icmp_seq=0 ttl=255 time=0 ms

64 bytes from 10.10.14.121: icmp_seq=1 ttl=255 time=0 ms

2) 이어서 2번째 창에서는 아래와 같이 tcpdump 명령을 en0 interface를 통해 저 목적지로 오가는 ICMP protocol에 대해서만 수행합니다.

/ # tcpdump -i en0 ip proto \\icmp and host 10.10.14.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes

18:56:34.807504 IP 10.10.14.100 > aix61: ICMP echo request, id 320, seq 35, length 64

18:56:34.807528 IP aix61 > 10.10.14.100: ICMP echo reply, id 320, seq 35, length 64

18:56:35.807606 IP 10.10.14.100 > aix61: ICMP echo request, id 320, seq 36, length 64

18:56:35.807633 IP aix61 > 10.10.14.100: ICMP echo reply, id 320, seq 36, length 64

이 경우 seq 35 packet의 경우 18:56:34.807504와 18:56:34.807528의 차이, 즉 0.024msec가 응답 시간입니다.

seq 36 packet은 18:56:35.807606와 18:56:35.807633의 차이, 즉 0.027msec가 응답 시간입니다.

** 이 값들은 같은 물리적 서버 위에 구성된 VM 간의 virtual ethernet의 속도이므로 실제 물리적 switch를 거치는 값에 비해 매우 빠른 값입니다.

2021년 8월 10일 화요일

기존 VG의 pvid를 변경하는 절차 정리

이유가 어떻건 간에 pvid를 바꿔야 하는 경우가 있을 수 있습니다. 이때 기존 VG의 data를 파손하지 않으면서 그렇게 할 수 있는 방법은 chdev 명령으로 pv=clear를 하고난 뒤 recreatevg를 하는 것입니다. 아래와 같이 정리했습니다.

기존 pvid와 VG name, 그리고 LV name 등을 확인합니다. 여기서 hdisk1의 pvid를 바꾸겠습니다.

/ # lspv

hdisk0 00f6db0af58e9775 rootvg active

hdisk1 00f9d7b4aa7cc533 lthvg active

hdisk2 00f9d7b4afdd3f2e lthvg active

hdisk3 00f9d7b4afdd3ff4 lthvg active

hdisk4 00f9d7b41e2e58e1 None

hdisk5 00f9d7b4afdd409f lthvg active

hdisk6 00f9d7b42df8691c lthvg active

/ # lsvg -l lthvg

lthvg:

LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT

loglv00 jfs2log 1 1 1 open/syncd N/A

fslv00 jfs2 12800 12800 5 open/syncd /trace

먼저 filesystem을 umount하고 VG를 내립니다. 그리고 VG도 exportvg 합니다.

/ # umount /trace

/ # varyoffvg lthvg

/ # exportvg lthvg

이제 hdisk1의 pvid를 clear 하겠습니다.

/ # chdev -l hdisk1 -a pv=clear

hdisk1 changed

/ # lspv

hdisk0 00f6db0af58e9775 rootvg active

hdisk1 none None

hdisk2 00f9d7b4afdd3f2e None

hdisk3 00f9d7b4afdd3ff4 None

hdisk4 00f9d7b41e2e58e1 None

hdisk5 00f9d7b4afdd409f None

hdisk6 00f9d7b42df8691c None

그 다음에 recreatevg 명령을 내립니다. 이때, 반드시 -Y LA -L / 이라는 옵션을 붙여야 기존 LV name 등이 변경되지 않는다는 점에 유의하십시요. 또한 기존 VG의 모든 hdisk 번호들을 다 명기해야 합니다.

/ # recreatevg -y lthvg -Y NA -L / hdisk1 hdisk2 hdisk3 hdisk5 hdisk6

lthvg

이제 pvid가 새로운 것이 주어진 것을 보실 수 있습니다.

/ # lspv

hdisk0 00f6db0af58e9775 rootvg active

hdisk1 00f9d7b42f325d3b lthvg active

hdisk2 00f9d7b42f325db6 lthvg active

hdisk3 00f9d7b42f325e48 lthvg active

hdisk4 00f9d7b41e2e58e1 None

hdisk5 00f9d7b42f325ec8 lthvg active

hdisk6 00f9d7b42f325f41 lthvg active

varyonvg한 뒤, 기존 LV 등이 기존과 똑같이 보존된 것을 확인하시면 됩니다.

/ # varyonvg lthvg

/ # lsvg -l lthvg

lthvg:

LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT

loglv00 jfs2log 1 1 1 closed/syncd N/A

fslv00 jfs2 12800 12800 5 closed/syncd /trace

/ # mount /trace

/ # ls -l /trace

total 46662784

-rw-r----- 1 root system 16502636544 Jun 21 04:52 64C_0620_.CCA.tar

drwxr-xr-x 12 root system 94208 Jun 21 07:34 64C_0620_CAA

drwxr-xr-x 2 root system 20480 Jun 20 20:16 64C_0621_CAA_nodelayack

-rw-r----- 1 root system 5218713600 Jun 21 03:52 64C_0621_CAA_nodelayack.tar

2021년 7월 20일 화요일

DPO (Dynamic Platform Optimizer) 사용 방법

먼저 전체 시스템의 현재 DPO score를 계산해봅니다.

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V -r sys -o currscore

curr_sys_score=67

각 LPAR 별로 현재 점수가 어떤지 계산해봅니다.

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V -r lpar -o currscore

lpar_name=s824_vios2,lpar_id=1,curr_lpar_score=100

lpar_name=aaaa,lpar_id=2,curr_lpar_score=100

lpar_name=s824_vios1,lpar_id=3,curr_lpar_score=100

lpar_name=AIX72CloudVM_00,lpar_id=4,curr_lpar_score=90

lpar_name=DB2CF01,lpar_id=5,curr_lpar_score=100

lpar_name=aysun-05955fd8-00000006,lpar_id=6,curr_lpar_score=100

lpar_name=AIX7200_04_02_cldrdy,lpar_id=7,curr_lpar_score=51

lpar_name=tibero6,lpar_id=8,curr_lpar_score=50

lpar_name=RHEL_7.7,lpar_id=9,curr_lpar_score=100

lpar_name=kbs-ha01,lpar_id=10,curr_lpar_score=100

lpar_name=kbha02,lpar_id=11,curr_lpar_score=100

위에서 붉은 색으로 표시한 ID 7번 파티션을 DPO로 최적화하는 경우, 가능한 to-be 점수가 어떻게 되는지 산정해봅니다.

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V -r lpar -o calcscore --id 7

lpar_name=s824_vios2,lpar_id=1,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=aaaa,lpar_id=2,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=s824_vios1,lpar_id=3,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=AIX72CloudVM_00,lpar_id=4,curr_lpar_score=90,predicted_lpar_score=90

lpar_name=DB2CF01,lpar_id=5,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=aysun-05955fd8-00000006,lpar_id=6,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=AIX7200_04_02_cldrdy,lpar_id=7,curr_lpar_score=51,predicted_lpar_score=100

lpar_name=tibero6,lpar_id=8,curr_lpar_score=50,predicted_lpar_score=100

lpar_name=RHEL_7.7,lpar_id=9,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=kbs-ha01,lpar_id=10,curr_lpar_score=100,predicted_lpar_score=100

lpar_name=kbha02,lpar_id=11,curr_lpar_score=100,predicted_lpar_score=100

위와 같이 100점 만점으로 최적화될 수 있습니다. 뿐만 아니라 그 밑의 ID 8번 파티션도 함께 최적화되어 점수가 100점이 되는 것을 보실 수 있습니다.

먼저 ID 7번 파티션의 SRAD 상태가 어떤지 확인해봅니다.

/ # lssrad -av

REF1 SRAD MEM CPU

0 53463.19 0-3 12-15 24-27 36-39 48-51 60-63 76-79 92-95 108-111 124-127 140-143 156-159 172-175 188-191 204-207 220-223 236-239 252-255

3 36105.00 72-75 88-91 104-107 120-123 136-139 152-155 168-171 184-187 200-203 216-219 232-235 248-251

1 53037.00 4-7 16-19 28-31 40-43 52-55 64-67 80-83 96-99 112-115 128-131 144-147 160-163 176-179 192-195 208-211 224-227 240-243

2 52539.00 8-11 20-23 32-35 44-47 56-59 68-71 84-87 100-103 116-119 132-135 148-151 164-167 180-183 196-199 212-215 228-231 244-247

별로 좋지는 않네요. 다음과 같이 7번 파티션에 대해 DPO 최적화를 수행하도록 optmem 명령을 수행합니다.

hscroot@icchmc:~> optmem -m Server-8286-42A-SN84D7B4V -o start -t affinity --id 7

이건 작은 시스템이라서 1~2분이면 완료됩니다. 점수를 다시 확인해봅니다.

hscroot@icchmc:~> lsmemopt -m Server-8286-42A-SN84D7B4V -r lpar -o currscore

lpar_name=s824_vios2,lpar_id=1,curr_lpar_score=100

lpar_name=aaaa,lpar_id=2,curr_lpar_score=100

lpar_name=s824_vios1,lpar_id=3,curr_lpar_score=100

lpar_name=AIX72CloudVM_00,lpar_id=4,curr_lpar_score=100

lpar_name=DB2CF01,lpar_id=5,curr_lpar_score=100

lpar_name=aysun-05955fd8-00000006,lpar_id=6,curr_lpar_score=100

lpar_name=AIX7200_04_02_cldrdy,lpar_id=7,curr_lpar_score=100

lpar_name=tibero6,lpar_id=8,curr_lpar_score=100

lpar_name=RHEL_7.7,lpar_id=9,curr_lpar_score=100

lpar_name=kbs-ha01,lpar_id=10,curr_lpar_score=100

lpar_name=kbha02,lpar_id=11,curr_lpar_score=100

7번 뿐만 아니라 8번, 그리고 심지어 90점 정도가 될 거라고 했던 4번 파티션도 다 100점 만점으로 변화한 것을 보실 수 있습니다.

실제로 그런지 7번 파티션 속에 들어가서 SRAD를 확인합니다. 아래와 같이 (64MB 정도를 제외한) 전체 CPU core 및 memory가 REF1로 이동한 것을 보실 수 있습니다.

/ # lssrad -av

REF1 SRAD MEM CPU

0 64.25

3 0.00

1 98102.00 4-7 12-15 20-23 28-31 36-39 44-47 52-55 60-63 68-71 76-79 84-87 92-95 100-103 108-111 116-119 124-127 132-135 140-143 148-151 156-159 164-167 172-175 180-183 188-191 196-199 204-207 212-215 220-223 228-231 236-239 244-247 252-255

2 96977.94 0-3 8-11 16-19 24-27 32-35 40-43 48-51 56-59 64-67 72-75 80-83 88-91 96-99 104-107 112-115 120-123 128-131 136-139 144-147 152-155 160-163 168-171 176-179 184-187 192-195 200-203 208-211 216-219 224-227 232-235 240-243 248-251

2021년 7월 1일 목요일

CAA gw_ip list에서 특정 IP를 제거하는 방법

AIX 7.1부터 도입된 CAA (Cluster Aware AIX)는 PowerHA 7.1 이상에서 cluster 구성을 위해 사용하는 일종의 AIX kernel extenstion이고, PowerHA의 일부가 아니라 AIX의 일부로서 bos.cluster.rte에 포함되어 있습니다.

CAA는 PowerHA의 heartbeat과는 별도로 heartbeat을 교환하며, 거기에 사용되는 IP addr의 목록을 gw_ip list라는 곳에서 관리합니다. 이는 PowerHA에 등록되고 구성된 network interface와는 별도로 관리되는 것입니다만, 처음 구성에서는 PowerHA에서 구성된 network interface 정보들을 그대로 가져옵니다.

아래의 간단한 테스트 클러스터를 보시겠습니다. Hostname이 kbs-ha01과 kbs-ha02인 2개의 node를 이용하여 test_cluster라는 PowerHA cluster를 구성하겠습니다. 아래와 같이 각 node에는 en0~en2까지 3개의 interface가 있습니다.

kbs-ha01:/>hostname

kbs-ha01

kbs-ha01:/>netstat -i

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

en0 1500 link#2 fa.6f.5.8d.af.20 3605951 0 900051 0 0

en0 1500 10.10.14.64 kbs-ha01 3605951 0 900051 0 0

en1 1500 link#3 fa.16.3e.3b.b2.4 3155242 0 668052 0 0

en1 1500 192.168.10 kbs_ha01_priv01 3155242 0 668052 0 0

en2 1500 link#4 fa.16.3e.8d.6e.4f 3111172 0 649586 0 0

en2 1500 8.1.1 kbs_ha01_priv02 3111172 0 649586 0 0

lo0 16896 link#1 152004 0 152004 0 0

lo0 16896 127 loopback 152004 0 152004 0 0

lo0 16896 loopback 152004 0 152004 0 0

여기서 우리가 원하는 것은 PowerHA node name은 hostname인 kbs-ha01과 kbs-ha02로 하되, 이 interface들은 CAA에서 관리하는 gw_ip list에서 빠지도록 하는 것입니다. 먼저 평범하게 PowerHA에서 test_cluster라는 이름으로 cluster를 구성하고 거기에 'Discover Network Interfaces and Disks'를 통해 발견된 network 정보를 이용하여 3개의 interface를 그대로 등록하겠습니다.

Manage Networks and Network Interfaces

Move cursor to desired item and press Enter.

Networks

Network Interfaces

Show Topology Information by Network

Show Topology Information by Network Interface

Verify and Synchronize Cluster Configuration

Networks

Move cursor to desired item and press Enter.

Add a Network

Change/Show a Network

Remove a Network

+--------------------------------------------------------------------------+

| Select a Network to Change/Show |

| |

| Move cursor to desired item and press Enter. |

| |

| net_ether_01 (192.168.10.0/24 8.1.1.0/24) |

| net_ether_010 (10.10.14.64/26) |

| |

Change/Show a Network

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

[Entry Fields]

* Network Name net_ether_010

New Network Name []

* Network Type [ether] +

* Netmask(IPv4)/Prefix Length(IPv6) [255.255.255.192]

* Network attribute public +

이렇게 구성한 뒤 PowerHA의 'Verify and Synchronize Cluster Configuration' 메뉴를 수행하면 일단 test_cluster가 구성되고, 그와 동시에 CAA의 특징인 caavg_private Volume Group이 만들어집니다. 또한 이때 gw_ip list도 PowerHA에 등록된 저 3개의 interface (192.168.10.0/24, 8.1.1.0/24, 10.10.14.64/26)를 모두 가져와서 등록합니다. 이렇게 등록된 gw_ip list는 아래 명령어로 확인 가능합니다.

kbs-ha01:/>/usr/lib/cluster/clras dumprepos | grep -p gw_

NODES

Name Uuid N_gw Site_uuid

kbs-ha01 d785c6a4-da2e-11eb-8048-fa6f058daf20 3 51735173-5173-5173-5173-517351735173

gw_flag : 1

gw_ip

192.168.10.21

8.1.1.21

10.10.14.94

kbs-ha02 d785c726-da2e-11eb-8048-fa6f058daf20 3 51735173-5173-5173-5173-517351735173

gw_flag : 1

gw_ip

192.168.10.22

8.1.1.22

10.10.14.123

위와 같이 node당 3개의 IP가 다 등록된 것을 보실 수 있습니다. 이 IP들을 통해서 들어오는 모든 network packet들은 CAA의 점검 대상이 됩니다. 그런 점검으로 인한 overhead를 피하고자 한다면, gw_ip list에 포함되는 IP들은 오로지 cluster heartbeat만을 위한 별도 network으로 구성해야 합니다. 지금 우리의 경우처럼 이미 PowerHA node name으로 10.10.14.64/26 network의 IP name들, 즉 kbs-ha01과 kbs-ha02를 사용한 경우, 이 IP를 PowerHA에서 제거하는 것은 곤란합니다. 이럴 때는 어떻게 해야 할까요?

이건 PowerHA network 속성 중에서 default인 public 대신 private을 사용하면 됩니다. 아래와 같이 'Change/Show a Network' 메뉴를 이용하여 10.10.14.64/26 network을 private으로 바꿔 줍니다.

Networks

Move cursor to desired item and press Enter.

Add a Network

Change/Show a Network

Remove a Network

+--------------------------------------------------------------------------+

| Select a Network to Change/Show |

| |

| Move cursor to desired item and press Enter. |

| |

| net_ether_01 (192.168.10.0/24 8.1.1.0/24) |

| net_ether_010 (10.10.14.64/26) |

| |

Change/Show a Network

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

[Entry Fields]

* Network Name net_ether_010

New Network Name []

* Network Type [ether] +

* Netmask(IPv4)/Prefix Length(IPv6) [255.255.255.192]

* Network attribute private +

+--------------------------------------------------------------------------+

| Network attribute |

| |

| Move cursor to desired item and press Enter. |

| |

| public |

| private |

| |

그러고난 뒤에 'Verify and Synchronize Cluster Configuration'를 수행하면 다음과 같이 chcluster 명령으로 10.10.14.123과 10.10.14.94가 제거되는 것을 보실 수 있습니다. (-cle_ip는 제거, +cle_ip는 추가입니다.)

Manage Networks and Network Interfaces

Move cursor to desired item and press Enter.

Networks

Network Interfaces

Show Topology Information by Network

Show Topology Information by Network Interface

Verify and Synchronize Cluster Configuration

...

Checking for added nodes

Thu Jul 1 00:49:52 CDT 2021 cldare[3278]: Updating the CAA adapter configuration to match the SystemMirror configuration.

Thu Jul 1 00:49:52 CDT 2021 cldare[3382]: Removing adapter en0 with IP address 10.10.14.123 on node kbs-ha02 from CAA

CLUSTER_OVERRIDE=yes ODMDIR=/etc/objrepos chcluster -n test_cluster -m kbs-ha02{-cle_ip=10.10.14.123}

chcluster: Successfully modified cluster.

Thu Jul 1 00:49:54 CDT 2021 cldare[3382]: Removing adapter en0 with IP address 10.10.14.94 on node kbs-ha01 from CAA

CLUSTER_OVERRIDE=yes ODMDIR=/etc/objrepos chcluster -n test_cluster -m kbs-ha01{-cle_ip=10.10.14.94}

chcluster: Successfully modified cluster.

...

이제 다시 /usr/lib/cluster/clras dumprepos 명령으로 gw_ip list를 확인하면 위에서와는 달리 10.10.14.x interface가 사라진 것을 보실 수 있습니다.

kbs-ha01:/>/usr/lib/cluster/clras dumprepos | grep -p gw_

NODES

Name Uuid N_gw Site_uuid

kbs-ha01 d785c6a4-da2e-11eb-8048-fa6f058daf20 2 51735173-5173-5173-5173-517351735173

gw_flag : 1

gw_ip

192.168.10.21

8.1.1.21

kbs-ha02 d785c726-da2e-11eb-8048-fa6f058daf20 2 51735173-5173-5173-5173-517351735173

gw_flag : 1

gw_ip

192.168.10.22

8.1.1.22