HW 엔지니어를 위한 Deep Learning: redhat

레이블이 redhat인 게시물을 표시합니다. 모든 게시물 표시

2019년 11월 13일 수요일

Redhat ppc64le 서버에서 logstash를 설치하고 구성하기

IBM POWER9 서버, 즉 ppc64le 아키텍처 기반의 Redhat 서버에 logstash를 설치하고 구성하는 것을 간단히 해보겠습니다.

먼저, logstash는 java 기반이기 때문에, 그냥 x86_64용으로 elastic.co에서 제공되는 RPM 파일을 그냥 그대로 받아다 설치해서 쓰시면 됩니다.

[user607@p607-kvm1 ~]$ wget https://artifacts.elastic.co/downloads/logstash/logstash-7.4.2.rpm

[user607@p607-kvm1 ~]$ sudo rpm -Uvh logstash-7.4.2.rpm
warning: logstash-7.4.2.rpm: Header V4 RSA/SHA512 Signature, key ID d88e42b4: NOKEY
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:logstash-1:7.4.2-1 ################################# [100%]
Using provided startup.options file: /etc/logstash/startup.options
OpenJDK 64-Bit Server VM warning: TieredCompilation is disabled in this release.
/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/pleaserun-0.0.30/lib/pleaserun/platform/base.rb:112: warning: constant ::Fixnum is deprecated
Successfully created system startup script for Logstash

다만 이걸 그대로 수행해보시면 아래와 같이 "load error: ffi/ffi" error가 나는 것을 보실 수 있습니다.

[root@p607-kvm1 user607]# /usr/share/logstash/bin/logstash
Thread.exclusive is deprecated, use Thread::Mutex
WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults
Could not find log4j2 configuration at path /usr/share/logstash/config/log4j2.properties. Using default config which logs errors to the console
[INFO ] 2019-11-12 23:56:52.605 [main] writabledirectory - Creating directory {:setting=>"path.queue", :path=>"/usr/share/logstash/data/queue"}
[INFO ] 2019-11-12 23:56:52.633 [main] writabledirectory - Creating directory {:setting=>"path.dead_letter_queue", :path=>"/usr/share/logstash/data/dead_letter_queue"}
[ERROR] 2019-11-12 23:56:53.198 [LogStash::Runner] Logstash - java.lang.IllegalStateException: Logstash stopped processing because of an error: (LoadError) load error: ffi/ffi -- java.lang.NullPointerException: null

이는 https://github.com/elastic/logstash/issues/10755 에 기술된 bug 때문인데, 요약하면 jruby-complete-*.jar 파일 안의 powerpc64le-linux platform을 위한 directory에 실수로 platform.conf가 빠져 있기 때문에 발생하는 것입니다. 이는 아래와 같은 command로 간단히 확인하실 수 있습니다. 일단 아래와 같이 error가 나는지 확인하십시요.

[root@p607-kvm1 user607]# java -jar /usr/share/logstash/logstash-core/lib/jars/jruby-complete-9.2.8.0.jar -rffi -e 1
LoadError: load error: ffi/ffi -- java.lang.NullPointerException: null
require at org/jruby/RubyKernel.java:987
require at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:54
<main> at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/ffi.rb:1
require at org/jruby/RubyKernel.java:987
(root) at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:1

확인되면 아래와 같이 powerpc64le-linux/types.conf 파일을 추출해내십시요.

[root@p607-kvm1 user607]# jar -xvf /usr/share/logstash/logstash-core/lib/jars/jruby-complete-9.2.8.0.jar META-INF/jruby.home/lib/ruby/stdlib/ffi/platform/powerpc64le-linux/types.conf
inflated: META-INF/jruby.home/lib/ruby/stdlib/ffi/platform/powerpc64le-linux/types.conf

이 파일을 다음과 같이 powerpc64le-linux/platform.conf로 copy하십시요.

[root@p607-kvm1 user607]# cp META-INF/jruby.home/lib/ruby/stdlib/ffi/platform/powerpc64le-linux/types.conf META-INF/jruby.home/lib/ruby/stdlib/ffi/platform/powerpc64le-linux/platform.conf

이렇게 만들어진 powerpc64le-linux/platform.conf을 원래의 jruby-complete-*.jar 파일에 update하십시요.

[root@p607-kvm1 user607]# jar -uvf /usr/share/logstash/logstash-core/lib/jars/jruby-complete-9.2.8.0.jar META-INF/jruby.home/lib/ruby/stdlib/ffi/platform/powerpc64le-linux/platform.conf
adding: META-INF/jruby.home/lib/ruby/stdlib/ffi/platform/powerpc64le-linux/platform.conf(in = 3796) (out= 483)(deflated 87%)

이제 다시 테스트해보면 "load error: ffi/ffi"가 더 발생하지 않는 것을 보실 수 있습니다.

[root@p607-kvm1 user607]# java -jar /usr/share/logstash/logstash-core/lib/jars/jruby-complete-9.2.8.0.jar -rffi -e 1

[root@p607-kvm1 user607]# echo $?
0

이제 간단한 logstash config 파일을 작성합니다. 여기서는 /tmp/in.log에 뭔가 내용이 쌓이면 그걸 grok으로 filtering한 뒤 rubydebug codec으로 format하여 /tmp/out.log에 집어넣는 것입니다.

[root@p607-kvm1 user607]# vi logstash-simple.conf
input {
file {
path => "/tmp/in.log"
}
}

filter {
grok {
match => { "message" => "%{NUMBER:timestamp} %{NUMBER:channel} %{MAC:client_mac} %{MAC:mac} %{INT:rssi}" }
}
}

output {
file {
path => "/tmp/out.log"
}
stdout { codec => rubydebug }
}

아래와 같이 logstash를 start 합니다.

[root@p607-kvm1 user607]# /usr/share/logstash/bin/logstash -f logstash-simple.conf
Thread.exclusive is deprecated, use Thread::Mutex
WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults
Could not find log4j2 configuration at path /usr/share/logstash/config/log4j2.properties. Using default config which logs errors to the console
[WARN ] 2019-11-13 00:23:47.244 [LogStash::Runner] multilocal - Ignoring the 'pipelines.yml' file because modules or command line options are specified
[INFO ] 2019-11-13 00:23:47.267 [LogStash::Runner] runner - Starting Logstash {"logstash.version"=>"7.4.2"}
[INFO ] 2019-11-13 00:23:50.305 [Converge PipelineAction::Create<main>] Reflections - Reflections took 75 ms to scan 1 urls, producing 20 keys and 40 values
[WARN ] 2019-11-13 00:23:52.059 [[main]-pipeline-manager] LazyDelegatingGauge - A gauge metric of an unknown type (org.jruby.RubyArray) has been create for key: cluster_uuids. This may result in invalid serialization. It is recommended to log an issue to the responsible developer/development team.
[INFO ] 2019-11-13 00:23:52.065 [[main]-pipeline-manager] javapipeline - Starting pipeline {:pipeline_id=>"main", "pipeline.workers"=>16, "pipeline.batch.size"=>125, "pipeline.batch.delay"=>50, "pipeline.max_inflight"=>2000, :thread=>"#<Thread:0x370844ca run>"}
[INFO ] 2019-11-13 00:23:52.938 [[main]-pipeline-manager] file - No sincedb_path set, generating one based on the "path" setting {:sincedb_path=>"/usr/share/logstash/data/plugins/inputs/file/.sincedb_b3374bae0eefd65d5f3cdbcfd41ca004", :path=>["/tmp/in.log"]}
[INFO ] 2019-11-13 00:23:52.992 [[main]-pipeline-manager] javapipeline - Pipeline started {"pipeline.id"=>"main"}
[INFO ] 2019-11-13 00:23:53.081 [[main]<file] observingtail - START, creating Discoverer, Watch with file and sincedb collections
[INFO ] 2019-11-13 00:23:53.089 [Agent thread] agent - Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}
[INFO ] 2019-11-13 00:23:53.488 [Api Webserver] agent - Successfully started Logstash API endpoint {:port=>9600}

여기서 다음과 같이 일정 format의 string을 /tmp/in.log에 집어넣습니다.

[root@p607-kvm1 user607]# echo "1524708231.794252221 8 c0:4a:00:40:e6:0e c0:4a:00:40:AA:AA -68" >> /tmp/in.log

그러면 logstash의 standard output log에 아래와 같이 그에 대한 처리가 되는 메시지가 나오는 것을 보실 수 있습니다.

[INFO ] 2019-11-13 00:24:54.175 [[main]>worker9] file - Opening file {:path=>"/tmp/out.log"}
/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/awesome_print-1.7.0/lib/awesome_print/formatters/base_formatter.rb:31: warning: constant ::Fixnum is deprecated
{
"@timestamp" => 2019-11-13T05:24:53.785Z,
"path" => "/tmp/in.log",
"@version" => "1",
"host" => "p607-kvm1",
"tags" => [
[0] "_grokparsefailure"
],
"message" => "1524708231.794252221 8 c0:4a:00:40:e6:0e c0:4a:00:40:AA:AA -68"
}
[INFO ] 2019-11-13 00:25:11.708 [[main]>worker9] file - Closing file /tmp/out.log

그리고 그 결과로 아래와 같이 format된 string이 지정된 file로 저장된 것을 보실 수 있습니다.

[root@p607-kvm1 user607]# cat /tmp/out.log
{"@timestamp":"2019-11-13T05:24:53.785Z","path":"/tmp/in.log","@version":"1","host":"p607-kvm1","tags":["_grokparsefailure"],"message":"1524708231.794252221 8 c0:4a:00:40:e6:0e c0:4a:00:40:AA:AA -68"}

2019년 3월 19일 화요일

ppc64le 환경에서의 OFED libary와 FIO 설치 및 기본 테스트

Disk의 성능 측정을 위해 FIO를 쓰는 경우가 많습니다. FIO는 rpm으로도 제공되며, 아래에서 download 받으시면 됩니다.

[u0017649@sys-97540 files]$ wget http://mirror.premi.st/epel/7/ppc64le/Packages/f/fio-3.1-1.el7.ppc64le.rpm

다만 이 FIO는 OFED library와 libaio를 prerequisite으로 필요로 하므로, 미리 이것들을 설치해야 합니다. libaio야 OS에 포함된 것을 그대로 쓰면 됩니다.

[u0017649@sys-97540 files]$ sudo yum install -y libaio

OFED library는 다음의 Mellanox 홈페이지에서 ppc64le용 패키지를 download 받으실 수 있습니다.

http://www.mellanox.com/page/products_dyn?product_family=26

먼저 OFED library가 요구하는 OS prerequisite을 설치해야 합니다.

[u0017649@sys-97540 files]$ sudo yum install -y pciutils lsof tcl gcc-gfortran libgfortran tcsh tk

[u0017649@sys-97540 files]$ ls -l *.tgz
-rw-rw-r--. 1 u0017649 u0017649 236217006 Mar 18 21:14 MLNX_OFED_LINUX-4.5-1.0.1.0-rhel7.5alternate-ppc64le.tgz

[u0017649@sys-97540 files]$ tar -zxf MLNX_OFED_LINUX-4.5-1.0.1.0-rhel7.5alternate-ppc64le.tgz

압축 해제된 directory 속에 들어가보면 script들이 몇개 보입니다.

[u0017649@sys-97540 files]$ cd MLNX_OFED_LINUX-4.5-1.0.1.0-rhel7.5alternate-ppc64le

[u0017649@sys-97540 MLNX_OFED_LINUX-4.5-1.0.1.0-rhel7.5alternate-ppc64le]$ ls
common_installers.pl docs mlnxofedinstall src
common.pl is_kmp_compat.sh RPM-GPG-KEY-Mellanox uninstall.sh
create_mlnx_ofed_installers.pl LICENSE RPMS
distro mlnx_add_kernel_support.sh RPMS_UPSTREAM_LIBS

이제 mlnxofedinstall script를 수행하면 OFED libary가 설치됩니다.

[u0017649@sys-97540 MLNX_OFED_LINUX-4.5-1.0.1.0-rhel7.5alternate-ppc64le]$ sudo ./mlnxofedinstall
(저는 실제로는 RHEL7.5ALT ppc64le 환경을 구할 수 없어서 그냥 RHEL7.4 ppc64le에서 MLNX_OFED_LINUX-4.5-1.0.1.0-rhel7.4-ppc64le.tgz를 받아서 수행했습니다. 실제로는 해당 OS 버전에 정확히 맞는 버전을 download 받아서 수행하셔야 error가 나지 않습니다.)

Detected rhel7u4 ppc64le. Disabling installing 32bit rpms...
Logs dir: /tmp/MLNX_OFED_LINUX.7174.logs
General log file: /tmp/MLNX_OFED_LINUX.7174.logs/general.log
Verifying KMP rpms compatibility with target kernel...
This program will install the MLNX_OFED_LINUX package on your machine.
Note that all other Mellanox, OEM, OFED, RDMA or Distribution IB packages will be removed.
Those packages are removed due to conflicts with MLNX_OFED_LINUX, do not reinstall them.

Do you want to continue?[y/N]:y

Starting MLNX_OFED_LINUX-4.5-1.0.1.0 installation ...

Installing mlnx-ofa_kernel RPM
Preparing... ########################################
Updating / installing...
mlnx-ofa_kernel-4.5-OFED.4.5.1.0.1.1.g########################################
Configured /etc/security/limits.conf
Installing kmod-mlnx-ofa_kernel 4.5 RPM
Preparing... ########################################
kmod-mlnx-ofa_kernel-4.5-OFED.4.5.1.0.########################################
Installing mlnx-ofa_kernel-devel RPM
...
mlnxofed-docs-4.5-1.0.1.0 ########################################
Preparing... ########################################
mpitests_openmpi-3.2.20-e1a0676.45101 ########################################

Installation finished successfully.

Preparing... ################################# [100%]
Updating / installing...
1:mlnx-fw-updater-4.5-1.0.1.0 ################################# [100%]

Added 'RUN_FW_UPDATER_ONBOOT=no to /etc/infiniband/openib.conf

Attempting to perform Firmware update...
No devices found!

To load the new driver, run:
/etc/init.d/openibd restart

저는 이 시스템에 infiniband adapter가 없기 때문에 위와 같이 'No devices found!'라는 메시지가 나옵니다만, 여기서는 신경 안쓰셔도 됩니다. 다만 맨 마지막 메시지처럼, 새로 설치된 driver를 load하려면 리부팅까지는 필요없고 아래와 같은 명령을 내리시면 됩니다.

먼저 아래와 같이 lsmod 명령으로 IB 관련 모듈이 load된 것이 있는지 살펴 봅니다. 보시다시피 없습니다.

[u0017649@sys-97540 files]$ sudo lsmod | grep ib
libcrc32c 1614 1 xfs
ibmvscsi 34850 5
scsi_transport_srp 18042 1 ibmvscsi
ibmveth 32369 0

이제 아래 명령으로 driver를 load합니다.

[u0017649@sys-97540 files]$ sudo /etc/init.d/openibd restart
Unloading HCA driver: [ OK ]
Loading HCA driver and Access Layer: [ OK ]

다시 lsmod 명령으로 IB 관련 모듈이 load된 것이 있는지 살펴 봅니다. 아까와는 달리 뭔가가 많이 올라온 것을 보실 수 있습니다.

[u0017649@sys-97540 files]$ sudo lsmod | grep ib
ib_ucm 17919 0
ib_ipoib 196794 0
ib_cm 57708 3 rdma_cm,ib_ucm,ib_ipoib
ib_umad 19974 0
mlx5_ib 380860 0
ib_uverbs 135906 3 mlx5_ib,ib_ucm,rdma_ucm
mlx5_core 1040727 2 mlx5_ib,mlx5_fpga_tools
mlx4_ib 242651 0
ib_core 341508 10 rdma_cm,ib_cm,iw_cm,mlx4_ib,mlx5_ib,ib_ucm,ib_umad,ib_uverbs,rdma_ucm,ib_ipoib
mlx4_core 413829 2 mlx4_en,mlx4_ib
mlx_compat 28099 15 rdma_cm,ib_cm,iw_cm,mlx4_en,mlx4_ib,mlx5_ib,mlx5_fpga_tools,ib_ucm,ib_core,ib_umad,ib_uverbs,mlx4_core,mlx5_core,rdma_ucm,ib_ipoib
devlink 35827 4 mlx4_en,mlx4_ib,mlx4_core,mlx5_core
libcrc32c 1614 1 xfs
ibmvscsi 34850 5
scsi_transport_srp 18042 1 ibmvscsi
ibmveth 32369 0

이제 download 받은 FIO를 설치합니다. 설치 자체는 간단합니다.

[u0017649@sys-97540 files]$ sudo rpm -Uvh fio-3.1-1.el7.ppc64le.rpm warning: fio-3.1-1.el7.ppc64le.rpm: Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY
Preparing... ################################# [100%]
Updating / installing...
1:fio-3.1-1.el7 ################################# [100%]

이제 fio 명령이 생겼습니다.

[u0017649@sys-97540 files]$ which fio
/usr/bin/fio

제가 테스트하는 서버는 SATA 디스크를 가상으로 쪼개어 받은 매우 형편없는 spec의 포팅용 가상머신입니다. 따라서 제대로 된 성능 테스트는 아니라는 점을 미리 인지하시기 바랍니다.

기본적인 write 테스트를 해봅니다. numjobs=1로 돌리는데, CPU 사용량은 거의 없습니다.

[u0017649@sys-97540 files]$ time fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/tmp/test1 --bs=64k --iodepth=64 --size=500M --numjobs=1 --readwrite=randwrite --rwmixwrite=100
test: (g=0): rw=randwrite, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=64
fio-3.1
Starting 1 process
test: Laying out IO file (1 file / 500MiB)
Jobs: 1 (f=1): [w(1)][99.3%][r=0KiB/s,w=0KiB/s][r=0,w=0 IOPS][eta 00m:02s]
...

Run status group 0 (all jobs):
WRITE: bw=1924KiB/s (1970kB/s), 1924KiB/s-1924KiB/s (1970kB/s-1970kB/s), io=500MiB (524MB), run=266076-266076msec

Disk stats (read/write):
sda: ios=0/7363, merge=0/667, ticks=0/15785000, in_queue=15789550, util=100.00%

real 4m26.400s
user 0m0.328s
sys 0m0.457s

이번에는 numjobs를 2로 다시 해보았습니다. (OS memory cache 효과를 없애기 위해 filename에 다른 file 이름을 써야 합니다.) 처음의 numjobs=1보다는 빠르지만 물론 2배 빠른 것은 아닙니다.

[u0017649@sys-97540 files]$ time fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/tmp/test2 --bs=64k --iodepth=64 --size=500M --numjobs=2 --readwrite=randwrite --rwmixwrite=100
test: (g=0): rw=randwrite, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=64
...
fio-3.1
Starting 2 processes
test: Laying out IO file (1 file / 500MiB)
Jobs: 2 (f=2): [w(2)][99.3%][r=0KiB/s,w=0KiB/s][r=0,w=0 IOPS][eta 00m:03s]
...

Run status group 0 (all jobs):
WRITE: bw=2455KiB/s (2514kB/s), 1227KiB/s-1228KiB/s (1257kB/s-1257kB/s), io=1000MiB (1049MB), run=417045-417161msec

Disk stats (read/write):
sda: ios=0/14383, merge=0/1643, ticks=0/48880230, in_queue=48926190, util=100.00%

real 6m57.439s
user 0m0.737s
sys 0m0.848s

이번에는 디스크가 아닌 공유 메모리 상에 써보겠습니다. 아래와 같이 /dev/shm에 1.8G 여유 공간이 있습니다.

[u0017649@sys-97540 files]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 31G 7.3G 24G 24% /
devtmpfs 1.7G 0 1.7G 0% /dev
tmpfs 1.8G 23M 1.8G 2% /dev/shm
tmpfs 1.8G 23M 1.8G 2% /run
tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup
/dev/sda2 1014M 166M 849M 17% /boot
tmpfs 357M 0 357M 0% /run/user/1001

다만 이건 임시 메모리 파일시스템인 tmpfs이므로 버퍼를 쓰지 않는 --direct=1 옵션을 쓸 수 없습니다. 따라서 그냥 --direct=0 옵션을 택해야 합니다. 당연히 4GB/s의 우수한 속도가 나옵니다.

[u0017649@sys-97540 files]$ sudo fio --randrepeat=1 --ioengine=libaio --direct=0 --gtod_reduce=1 --name=test --filename=/dev/shm/test2 --bs=64k --iodepth=64 --size=500M --numjobs=2 --readwrite=randwrite --rwmixwrite=100
test: (g=0): rw=randwrite, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=64

...

Run status group 0 (all jobs):
WRITE: bw=3906MiB/s (4096MB/s), 1953MiB/s-2024MiB/s (2048MB/s-2123MB/s), io=1000MiB (1049MB), run=247-256msec

Read 테스트는 다음과 같이 합니다.

[u0017649@sys-97540 files]$ fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/tmp/test1 --bs=64k --iodepth=64 --size=1G --numjobs=2 --readwrite=randread --rwmixread=100 test: (g=0): rw=randread, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=64

...

Run status group 0 (all jobs):
READ: bw=13.2MiB/s (13.9MB/s), 6778KiB/s-6793KiB/s (6941kB/s-6956kB/s), io=2048MiB (2147MB), run=154363-154703msec

2019년 1월 9일 수요일

Redhat ppc64le 상에서의 hadoop 및 hive 설치

HortonWorks (HDP)를 사용하는 것이 정식이겠습니다만, 여기서는 source로부터 build하는 방법을 다루겠습니다.

먼저 다음과 같이 maven 등 필요 OS package들을 yum으로 설치합니다.

[bsyu@centos01 files]$ sudo yum install maven protobuf-compiler zlib-devel snappy-devel pkgconfig autoconf automake libtool

이어서 JAVA_HOME 등 환경변수를 설정합니다.

[bsyu@centos01 files]$ export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.ppc64le

[bsyu@centos01 files]$ export MAVEN_OPTS="-Xmx2048m"

# hadoop build

여기서는 hadoop 2.6.5를 build 하겠습니다. 그 source를 가져오고 압축을 해제합니다.

[bsyu@centos01 files]$ wget https://archive.apache.org/dist/hadoop/common/hadoop-2.6.5/hadoop-2.6.5-src.tar.gz

[bsyu@centos01 files]$ tar -zxf hadoop-2.6.5-src.tar.gz

[bsyu@centos01 files]$ cd hadoop-2.6.5-src/

Maven으로 build하는 명령은 아래와 같이 매우 간단합니다.

[bsyu@centos01 hadoop-2.6.0-src]$ mvn package -Pdist -DskipTests -Dtar -Dmaven.javadoc.skip=true

(원래 hadoop 2.6은 java 버전 7에서 지원되던 것입니다. 그래서 java 8 환경에서는 -Dmaven.javadoc.skip=true를 붙이지 않으면 javadoc 관련하여 error가 나는 부분이 있으니 꼭 붙이시기 바랍니다.)

이렇게 생성된 hadoop-2.6.5.tar.gz을 적당한 directory에 풀어놓으면 설치는 끝납니다. 여기서는 /home/hadoop-2.6.5 가 HADOOP_HOME 이 됩니다.

[bsyu@centos01 ~]$ sudo tar -zxf /home/bsyu/files/hadoop-2.6.5-src/hadoop-dist/target/hadoop-2.6.5.tar.gz -C /home

# hive build

여기서는 hive 1.1,1을 build 하겠습니다. 그 source를 가져오고 압축을 해제합니다.

[bsyu@centos01 files]$ wget https://github.com/apache/hive/archive/release-1.1.1.tar.gz

[bsyu@centos01 files]$ tar -zxf release-1.1.1.tar.gz

[bsyu@centos01 files]$ cd hive-release-1.1.1

다음과 같이 hadoop class를 지정해주고, 특히 hadoop v2 환경에서 사용할 것임을 지정하는 -Phadoop-2를 붙여서 maven으로 build 해주면 됩니다.

[bsyu@centos01 hive-release-1.1.1]$ mvn package -Pdist -Phadoop-2 -DskipTests -Dtar -Dmaven.javadoc.skip=true

...

[INFO] Building tar: /home/bsyu/files/hive-release-1.1.1/packaging/target/apache-hive-1.1.1-bin.tar.gz

...

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 10:10.367s

[INFO] Finished at: Wed Jan 09 11:27:01 KST 2019

[INFO] Final Memory: 179M/897M

[INFO] ------------------------------------------------------------------------

이렇게 생성된 apache-hive-1.1.1-bin.tar.gz을 적당한 directory에 풀어놓으면 설치는 끝납니다. 여기서는 /home/apache-hive-1.1.1-bin 이 HIVE_HOME 이 됩니다.

[bsyu@centos01 ~]$ sudo tar -zxf /home/bsyu/files/hive-release-1.1.1/packaging/target/apache-hive-1.1.1-bin.tar.gz -C /home

위에서 build한 hadoop-2.6.5.tar.gz 과 apache-hive-1.1.1-bin.tar.gz 를 Google drive에 올려놓았습니다.

hadoop-2.6.5.tar.gz : https://drive.google.com/open?id=12B1e6mBLBOOUW6oajwDMYTUap6iUIHEG

apache-hive-1.1.1-bin.tar.gz : https://drive.google.com/open?id=1Qg-fxWXFoqzwcXEjvXpL2sb9Tk9lssg-

2018년 8월 28일 화요일

nvidia-docker를 위한 Redhat 7.5 ppc64le docker image의 build

** 이 문서에서 서술하는 방식으로 만든 이미지들의 완성본을 다음의 주소에서 받으실 수 있습니다. IBM GPU 서버인 AC922이나 Minsky 서버를 위한 Redhat 7.5 ppc64le + CUDA 9.2 + cudnn 7.2.1 + NCCL 2.2 + PowerAI 5.2 + Anaconda 2 (py2) or Anaconda3 (py3) 기반으로 만들어진 이미지들입니다.

https://hub.docker.com/r/bsyu/rhel75_ppc64le_cuda92_all_py2_powerai52/
https://hub.docker.com/r/bsyu/rhel75_ppc64le_cuda92_all_py3_powerai52/

Pull 할 때는 다음과 같이 하시면 됩니다.

# docker pull bsyu/rhel75_ppc64le_cuda92_all_py2_powerai52:v0.4 (python2.7)
# docker pull bsyu/rhel75_ppc64le_cuda92_all_py3_powerai52:v0.3 (python3.6)

아래는 이 docker image들을 만들 때의 과정입니다.

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

먼저, 현재 host 서버의 OS(여기서는 Redhat 7.5 ALT ppc64le)를 기반으로 docker base image를 만듭니다. 아래 github에서 제공되는 mkimage-yum.sh를 사용하면 쉽습니다.

https://github.com/moby/moby/blob/master/contrib/mkimage-yum.sh

[root@ING ~]# cd docker

[root@ING docker]# vi mkimage-yum.sh # https://github.com/moby/moby/blob/master/contrib/mkimage-yum.sh의 script를 copy & paste

[root@ING docker]# chmod +x mkimage-yum.sh

[root@ING docker]# ./mkimage-yum.sh baserehel75alt
...
Running transaction
Installing : libgcc-4.8.5-28.el7_5.1.ppc64le 1/243
Installing : redhat-release-server-7.5-7.el7a.ppc64le 2/243
Installing : setup-2.8.71-9.el7.noarch 3/243
Installing : filesystem-3.2-25.el7.ppc64le 4/243
Installing : tzdata-2018e-3.el7.noarch 5/243
Installing : basesystem-10.0-7.el7.noarch 6/243
...
xz-libs.ppc64le 0:5.2.2-1.el7 yum-metadata-parser.ppc64le 0:1.1.4-10.el7
zlib.ppc64le 0:1.2.7-17.el7

Complete!
+ [[ -n '' ]]
+ yum -c /etc/yum.conf --installroot=/tmp/mkimage-yum.sh.Oh71td -y clean all
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
There are no enabled repos.
Run "yum repolist all" to see the repos you have.
To enable Red Hat Subscription Management repositories:
subscription-manager repos --enable <repo>
To enable custom repositories:
yum-config-manager --enable <repo>

Script가 위와 같이 성공적으로 완료된 뒤에 message에 표시된 /tmp 밑의 directory로 가보면 아래와 같이 mini-OS image가 마련되어 있는 것을 보실 수 있습니다.
이제 이걸 tar로 말아올린 뒤 docker import 명령으로 import 해주면 됩니다.

[root@ING docker]# cd /tmp/mkimage-yum.sh.Oh71td

[root@ING mkimage-yum.sh.Oh71td]# ls -ltr
total 12
dr-xr-xr-x 2 root root 6 Dec 15 2017 sys
drwxr-xr-x 2 root root 6 Dec 15 2017 srv
dr-xr-xr-x 2 root root 6 Dec 15 2017 proc
drwxr-xr-x 2 root root 6 Dec 15 2017 opt
drwxr-xr-x 2 root root 6 Dec 15 2017 mnt
drwxr-xr-x 2 root root 6 Dec 15 2017 media
drwxr-xr-x 2 root root 6 Dec 15 2017 home
drwxr-xr-x 2 root root 180 Dec 15 2017 dev
dr-xr-xr-x 2 root root 6 Dec 15 2017 boot
lrwxrwxrwx 1 root root 7 Aug 9 09:47 bin -> usr/bin
lrwxrwxrwx 1 root root 8 Aug 9 09:47 sbin -> usr/sbin
lrwxrwxrwx 1 root root 9 Aug 9 09:47 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 7 Aug 9 09:47 lib -> usr/lib
drwxr-xr-x 13 root root 207 Aug 9 09:47 usr
drwxrwxrwt 7 root root 117 Aug 9 09:47 tmp
drwxr-xr-x 19 root root 335 Aug 9 09:47 var
drwxr-xr-x 15 root root 261 Aug 9 09:47 run
drwxr-xr-x 68 root root 8192 Aug 9 09:47 etc
dr-xr-x--- 2 root root 91 Aug 9 09:47 root

[root@ING mkimage-yum.sh.Oh71td]# tar -zcf /tmp/rhel7_ppc64le.tar.gz .

[root@ING mkimage-yum.sh.Oh71td]# ls -l /tmp/rhel7_ppc64le.tar.gz
-rw-r--r-- 1 root root 224266718 Aug 9 10:15 /tmp/rhel7_ppc64le.tar.gz

[root@ING mkimage-yum.sh.Oh71td]# docker import /tmp/rhel7_ppc64le.tar.gz bsyu/rhel75_ppc64le:base

[root@ING mkimage-yum.sh.Oh71td]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
bsyu/rhel75_ppc64le base 3bf1baa60960 4 seconds ago 715 MB

이제 이 base image를 기반으로 dockerfile을 편집해서 CUDA 명령을 쓸 수 있는 nvidia-docker image를 만들면 됩니다.

그러기 위해서는 먼저 이 docker base image에서도 yum 명령을 써야 하는데, 기본적으로 Redhat에서 제공되는 /etc/yum.repos.d/redhat.repo 파일은 매번 yum을 기동할 때마다 자동으로 blank로 reset 되어버립니다. 따라서 이 파일 이름말고, 다른 이름, 가령 /etc/yum.repos.d/new.repo라는 이름으로 host OS에 있는 /etc/yum.repos.d/redhat.repo 파일을 그대로 저장해두면 host OS에서처럼 외부 YUM repository를 자유롭게 쓸 수 있습니다. 물론 이때 /etc/pki/entitlement/*-key.pem 등의 필요 ceritificate 파일들도 함께 docker image 속의 /etc/pki/entitlement에 copy 해두어야 합니다. 가령 다음과 같이 하면 됩니다.

[bsyu@p57a22 ~]# docker run -ti --rm -v /etc:/mnt bsyu/rhel75_ppc64le:base bash

----inside docker container------

[root@7e3b00f3fac2 ~]# cp /mnt/pki/entitlement/*.pem /etc/pki/entitlement

[root@7e3b00f3fac2 ~]# cp /mnt/yum.repos.d/redhat.repo /etc/yum.repos.d/new.repo # 절대 redhat.repo라는 이름으로 copy하면 안 됩니다.

[root@7e3b00f3fac2 ~]# rpm -Uvh /mnt/epel-release-7-11.noarch.rpm # epel-release-7-11.noarch.rpm 파일의 경우 host의 /etc 밑에 미리 copy해둡니다.

[root@7e3b00f3fac2 ~]# yum install wget curl cmake cmake3 make automake autoconf bzip2 zip unzip git gcc gcc-c++ gfortran yum-utils # 기본적으로 필요한 package들을 미리 설치해둡니다.

----outside docker container------

[bsyu@p57a22 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7e3b00f3fac2 bsyu/rhel75_ppc64le:base bash "bash" 23 hours ago Up 23 hours angry_bose

[bsyu@p57a22 ~]# docker commit 7e3b00f3fac2 bsyu/rhel75_ppc64le:base_v6

이제 dockerfile을 이용하여 nvidia-docker 이미지를 만듭니다. 먼저 (다른 이름도 상관없습니다만) docker라는 directory를 만들고, 거기에 docker image 속에 설치할 cuda*.rpm 등을 미리 copy 해둡니다. 그리고나서 dockerfile.cuda92 파일을 다음과 같이 만듭니다.

[bsyu@p57a22 ~]# mkdir /home/docker && cd /home/docker

[root@p57a22 docker]# vi dockerfile.cuda92
FROM bsyu/rhel75_ppc64le:base_v6

# Update image
# 'local' means rhel local repository
# To use these repos below in building process, you must set up the RHEL subscription and enable these repos on your host system first.
RUN yum-config-manager --enable rhel-7-for-power-9-rpms/7Server/ppc64le
RUN yum-config-manager --enable rhel-7-for-power-9-optional-rpms/7Server/ppc64le
RUN yum-config-manager --enable rhel-7-for-power-9-extras-rpms/7Server/ppc64le
RUN yum-config-manager --enable epel/ppc64le

RUN mkdir /tmp/temp
COPY cuda-repo-rhel7-9-2-local* /tmp/temp/
RUN rpm -Uvh /tmp/temp/cuda-repo-rhel7-9-2-local*
RUN yum install -y cuda

# nvidia-docker 1.0
LABEL com.nvidia.volumes.needed="nvidia_driver"
LABEL com.nvidia.cuda.version="${CUDA_VERSION}"

RUN echo "/usr/local/nvidia/lib" >> /etc/ld.so.conf.d/nvidia.conf && \
echo "/usr/local/nvidia/lib64" >> /etc/ld.so.conf.d/nvidia.conf

ENV PATH /usr/local/nvidia/bin:/usr/local/cuda/bin:${PATH}
ENV LD_LIBRARY_PATH /usr/local/nvidia/lib:/usr/local/nvidia/lib64:/usr/local/cuda/lib64/stubs

# nvidia-container-runtime
ENV NVIDIA_VISIBLE_DEVICES all
ENV NVIDIA_DRIVER_CAPABILITIES compute,utility
ENV NVIDIA_REQUIRE_CUDA "cuda>=9.2"

RUN yum clean all && rm -rf /var/cache/yum/* /tmp/temp
RUN rpm -e cuda-repo-rhel7-9-2-local

이제 위의 dockerfile.cuda92 파일을 이용하여 다음과 같이 bsyu/rhel75_ppc64le_cuda92_all:v0.1라는 이름으로 docker image를 build합니다.

[root@p57a22 docker]# docker build -t bsyu/rhel75_ppc64le_cuda92_all:v0.1 -f dockerfile.cuda92 .
Sending build context to Docker daemon 1.705 GB
Step 1/24 : FROM docker.io/bsyu/rhel75_ppc64le:base_v5
---> fc88cbad6b18
....
Cleaning up everything
Maybe you want: rm -rf /var/cache/yum, to also free up space taken by orphaned data from disabled or removed repos
---> f26c0a2167a0
Removing intermediate container bb911c868f27
Step 26/26 : RUN rpm -e cuda-repo-rhel7-9-2-local
---> Running in 6bceb027f2f1

---> deaf06286bf4
Removing intermediate container 6bceb027f2f1
Successfully built deaf06286bf4

다음과 같이 지정한 이름의 docker image가 생성된 것을 확인합니다.

[root@p57a22 docker]# docker images | grep bsyu
bsyu/rhel75_ppc64le_cuda92_all v0.1 deaf06286bf4 45 seconds ago 8.11 GB
bsyu/rhel75_ppc64le base_v6 872374a229f2 8 minutes ago 1.35 GB

이제 nvidia-docker로 이 image를 구동하여 nvidia-smi가 제대로 작동하는지 확인합니다. 그리고 PowerAI나 libcudnn* libnccl2* 등 필요 SW를 더 설치한 뒤 commit 하여 필요한 image를 추가로 만듭니다.

[bsyu@p57a22 data]$ nvidia-docker run -ti --rm -v /home/bsyu/files:/mnt bsyu/rhel75_ppc64le_cuda92_all:v0.1 bash

----inside docker container------

[root@e8a6f36fb132 /]# nvidia-smi
Thu Aug 23 01:28:52 2018
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 396.26 Driver Version: 396.26 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla P100-SXM2... Off | 00000002:01:00.0 Off | 0 |
| N/A 28C P0 29W / 300W | 10MiB / 16280MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla P100-SXM2... Off | 00000003:01:00.0 Off | 0 |
| N/A 30C P0 32W / 300W | 10MiB / 16280MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 2 Tesla P100-SXM2... Off | 0000000A:01:00.0 Off | 0 |
| N/A 28C P0 29W / 300W | 10MiB / 16280MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 3 Tesla P100-SXM2... Off | 0000000B:01:00.0 Off | 0 |
| N/A 31C P0 29W / 300W | 10MiB / 16280MiB | 0% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+

2018년 7월 3일 화요일

Redhat ppc64le에서의 OS disk mirroring (SW RAID1)

기존 posting http://hwengineer.blogspot.com/2017/03/ppc64le-power8-ubuntu-sw-raid.html 에서는 Ubuntu ppc64le 환경에서 mdadm device (SW RAID1) 구성을 통해 2장의 내장 disk에 OS mirror를 구성하는 방법을 소개시켜 드렸습니다. 아시다시피 x86 아키텍처와는 달리 ppc64le에는 boot loader를 보관하는 PReP이라는 파티션이 디스크 맨 앞 부분에 존재해야 하는데, 이것은 mdadm으로는 mirror가 되지 않습니다. 다만 이 boot loader는 한번 설치되면 거기에 추가로 write될 일이 없으므로, dd 명령어를 통해 source에서 target으로 copy만 떠 놓으면 OS mirror를 사용하는데 지장이 없습니다. 그를 위해서 사용한 작은 trick은, OS 설치시 먼저 양쪽 disk에 PReP을 포함한 모든 파티션을 만들어놓되, mdadm device는 PReP을 뺸 나머지 device에 대해서만 걸어두는 것이었습니다.

이제 POWER9과 V100을 장착한 AC922 서버는 현재까지는 주로 Redhat을 이용하는데, Redhat에서도 이런 OS mirror가 가능할까요 ? 불행히도 Redhat installer는 Ubuntu installer와는 약간 달라서, OS 설치시 각각의 disk에 먼저 파티션을 만든 뒤 어느 파티션을 무엇으로 사용할지 정하는 것이 아니라, 먼저 파티션 용도를 지정하면 자동으로 mirror device가 생성됩니다. 그래서 SW RAID1으로 그냥 설치하면 PReP과 /boot는 1번 disk에만 만들어지고, 2번 디스크 앞 부분에는 PReP 파티션을 만들 공간을 따로 확보할 수 없게 됩니다.

이 문제에 대한 workaround가 있습니다. 이 방법은 Kolon의 정유영 대리께서 고안해냈고, 테스트에서 1번 disk를 뽑아낸 뒤 리부팅을 해봐도 정상적으로 리부팅이 되었습니다. 수고해주신 정유영 대리께 감사드립니다.

이 workaround의 절차를 요약하면 아래와 같습니다.

1) 먼저 Redhat installer가 시키는 대로, PReP과 /boot를 제외한 OS mirror를 mdadm device를 구성하여 완료합니다.
2) OS 설치 완료 뒤 mdadm 명령으로 2번 디스크의 mirror copy를 제거하여 blank disk로 만듭니다.
3) 그렇게 비워진 2번 disk에 1번 disk와 동일한 크기로 PReP과 /boot를 포함한 파티션들을 새로 만듭니다.
4) 그 중 PReP과 /boot에는 dd 명령을 통해 1번 disk의 원본을 copy합니다.
5) 나머지 OS용 파티션에는 mdadm 명령으로 mirror copy를 새로 add 합니다.

간단하지요 ? 다만 이렇게 할 경우, 나중에 혹시 /boot에 뭔가 write를 할 일이 있다면 그 내용을 2번째 disk에 다시 dd 명령으로 write를 해줘야 하긴 합니다. 물론 /boot에는 write가 일어날 일은 거의 없습니다. 이제 위의 내용을 좀 더 자세히 정리해놓겠습니다.

1. 2개의 디스크중 "/"와 "swap" 부분을 mdadm device (즉 SW RAID1)으로 구성 해서 설치합니다. 이때 PReP과 /boot는 제외됩니다.
- PReP은 그렇다치고, 왜 /boot도 mdadm device로 구성이 안되는지는 의아하긴 합니다.

2. OS 설치 완료 후 OS 명령어 mdadm를 통해 MD device로 구성된 /와 swap에서 2번 디스크를 제거

# mdadm --manage /dev/md126 --remove /dev/sdb1 (swap 영역)
# mdadm --manage /dev/md127 --remove /dev/sdb2 (/ 영역)

3. 이제 텅 비게 된 2번 디스크를 1번 디스크와 동일하게 fdisk 명령을 이용해서 파티셔닝

# fdisk -l /dev/sda (1번 disk의 파티션 상황 파악)
# fdisk /dev/sdb (위의 정보에서 얻은 1번 disk 파티션과 동일하게 2번 disk에 파티션을 구성)
- 특히 맨 앞에 만드는 /dev/sdb1의 disk type은 41 (PPC PReP Boot)으로 구성해줘야 합니다.

# fdisk /dev/sda
...
Command (m for help): t
Hex code (type L to list all codes): 41
Changed type of partition 'Linux' to 'PPC PReP Boot'
...

그래서 다음과 같이 두 disk가 동일한 파티션 정보를 가지도록 만듭니다.

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 18431 8192 41 PPC PReP Boot
/dev/sda2 18432 1067007 524288 83 Linux
/dev/sda3 1067008 9455615 4194304 82 Linux swap / Solaris
/dev/sda4 9455616 1875384319 932964352 5 Extended
/dev/sda5 9457664 1875384319 932963328 8e Linux LVM

Device Boot Start End Blocks Id System
/dev/sdb1 2048 18431 8192 41 PPC PReP Boot
/dev/sdb2 18432 1067007 524288 83 Linux
/dev/sdb3 1067008 9455615 4194304 82 Linux swap / Solaris
/dev/sdb4 9455616 1875384319 932964352 5 Extended
/dev/sdb5 9457664 1875384319 932963328 8e Linux LVM

4. 이제 mdadm 명령으로 /와 swap 파티션의 mirror 구성을 실시합니다.

# mdadm --manage /dev/md126 --add /dev/sdb3 (swap 영역)
# mdadm --manage /dev/md127 --add /dev/sdb5 (/ 영역)

5. PReP 파티션을 dd 명령으로 복사합니다.

# dd if=/dev/sda1 of=/dev/sdb1 bs=1024k

6. /boot 파티션을 dd 명령으로 복사합니다. 단, 이 경우는 먼저 신규 /boot에 filesystem을 만들고, 또 기존 /boot를 umount하고 진행해야 합니다.

먼저 기존 /boot가 어떤 type의 filesystem으로 만들어졌는지 확인합니다. 여기서는 xfs로 되어 있습니다.

# mount | grep boot
/dev/sda2 on /boot type xfs (rw,relatime,attr2,inode64,noquota)

거기에 대응해서 동일 size로 만들어 두었던 /dev/sdb2를 xfs로 format 합니다. (이 format superblock은 dd로 copy가 안되더라고요)

# mkfs -t xfs -f /dev/sdb2

그 다음에 반드시 먼저 기존의 /boot를 umount 하고 dd를 뜹니다. (mount된 상태에서 dd를 뜨면 superblock이 copy 되지 않습니다.)

# umount /boot
# dd if=/dev/sda2 of=/dev/sdb2 bs=1024k

이제 보면 xfs_admin 명령으로 확인해보면 /dev/sdb2에도 /dev/sda2와 동일한 UUID가 들어가 있습니다. 이렇게 동일한 UUID를 사용하므로, /boot/grub2/grub.cfg를 굳이 수정할 필요가 없습니다. 다만 이로 인해 서버 부팅 시에 /boot로 /dev/sda2가 아니라 /dev/sdb2가 mount될 가능성도 있는데, 어차피 같은 copy이고 거기에 write가 일어날 일도 거의 없으므로 문제될 것은 없습니다.

# xfs_admin -u /dev/sda2
UUID = 20a94402-8589-48db-b8cf-e82c16f415ee

# xfs_admin -u /dev/sdb2
UUID = 20a94402-8589-48db-b8cf-e82c16f415ee

그리고 mount 해서 보면 원래의 /boot와 동일한 file들이 동일하게 보입니다.

# mount /dev/sda2 /boot
# mount /dev/sdb2 /mnt

# ls -l /boot
total 183444
-rw-r--r--. 1 root root 138001 Oct 17 2017 config-4.11.0-44.el7a.ppc64le
drwxr-xr-x. 3 root root 17 May 30 14:58 efi
drwx------. 5 root root 118 May 30 17:11 grub2
-rw-------. 1 root root 64932747 May 30 15:07 initramfs-0-rescue-168b61eb0f2d43cb8783c83d162b35f9.img
-rw-------. 1 root root 44154461 May 30 17:11 initramfs-4.11.0-44.el7a.ppc64le.img
-rw-------. 1 root root 22527454 May 30 15:27 initramfs-4.11.0-44.el7a.ppc64lekdump.img
-rw-r--r--. 1 root root 10382937 May 30 15:06 initrd-plymouth.img
-rw-r--r--. 1 root root 250055 Oct 17 2017 symvers-4.11.0-44.el7a.ppc64le.gz
-rw-------. 1 root root 2754018 Oct 17 2017 System.map-4.11.0-44.el7a.ppc64le
-rwxr-xr-x. 1 root root 21346760 May 30 15:07 vmlinuz-0-rescue-168b61eb0f2d43cb8783c83d162b35f9
-rwxr-xr-x. 1 root root 21346760 Oct 17 2017 vmlinuz-4.11.0-44.el7a.ppc64le

# ls -l /mnt
total 183444
-rw-r--r--. 1 root root 138001 Oct 17 2017 config-4.11.0-44.el7a.ppc64le
drwxr-xr-x. 3 root root 17 May 30 14:58 efi
drwx------. 5 root root 118 May 30 17:11 grub2
-rw-------. 1 root root 64932747 May 30 15:07 initramfs-0-rescue-168b61eb0f2d43cb8783c83d162b35f9.img
-rw-------. 1 root root 44154461 May 30 17:11 initramfs-4.11.0-44.el7a.ppc64le.img
-rw-------. 1 root root 22527454 May 30 15:27 initramfs-4.11.0-44.el7a.ppc64lekdump.img
-rw-r--r--. 1 root root 10382937 May 30 15:06 initrd-plymouth.img
-rw-r--r--. 1 root root 250055 Oct 17 2017 symvers-4.11.0-44.el7a.ppc64le.gz
-rw-------. 1 root root 2754018 Oct 17 2017 System.map-4.11.0-44.el7a.ppc64le
-rwxr-xr-x. 1 root root 21346760 May 30 15:07 vmlinuz-0-rescue-168b61eb0f2d43cb8783c83d162b35f9
-rwxr-xr-x. 1 root root 21346760 Oct 17 2017 vmlinuz-4.11.0-44.el7a.ppc64le

확인이 끝났으면 /mnt는 umount하고 사용을 시작하시면 됩니다.
# umount /mnt

이로써 OS mirroring이 다 끝난 것입니다.

2018년 5월 15일 화요일

Redhat ppc64le 환경에서의 OpenJDK 9과 OpenJFX의 build

앞선 posting은 OpenJDK 8에서 OpenJFX를 올린 것이었습니다만, 현재 OpenJFX의 current version은 JDK 9부터 지원됩니다. 이번 posting에서는 OpenJDK 9을 ppc64le 환경에서 build하고, 그를 지원하는 OpenJFX도 build해보겠습니다.

사전에 필요한 rpm package는 전과 동일하게 설치합니다.

[ibm@centos01 ~]$ sudo yum install mercurial bison flex gperf ksh pkgconfig libpng12-devel libjpeg-devel libxml2-devel libxslt-devel systemd-devel glib2-devel gtk2-devel pango-devel freetype-devel ant alsa-lib-devel freetype-devel cups-devel libXtst-devel libXt-devel libXrender-devel libXi-devel libX11-devel libXext-devel libffi-devel ccache make gcc gcc-c++ libstdc++-devel giflib-devel curl rpm-build gpg rpmbuild rpm-sign

OpenJFX의 current version에서는 gradle 4.3이 필요합니다.

[ibm@centos01 files]$ wget https://services.gradle.org/distributions/gradle-4.3-all.zip

[ibm@centos01 files]$ unzip gradle-4.3-all.zip

[ibm@centos01 files]$ cd gradle-4.3/bin

[ibm@centos01 bin]$ ./gradle --version

------------------------------------------------------------
Gradle 4.3
------------------------------------------------------------

Build time: 2017-10-30 15:43:29 UTC
Revision: c684c202534c4138b51033b52d871939b8d38d72

Groovy: 2.4.12
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_161 (Oracle Corporation 25.161-b14)
OS: Linux 3.10.0-693.11.6.el7.ppc64le ppc64le

이제 JDK 9 부터 build 합니다.

[ibm@centos01 ~]$ mkdir ~/openjdkathome && cd ~/openjdkathome

[ibm@centos01 openjdkathome]$ git clone https://github.com/hgomez/obuildfactory.git

다음과 같이 명령을 내리면 hg 명령을 통해 source를 추가로 download 받는 것부터 compile까지 일괄적으로 이루어집니다. hg download 과정이 특히 오래 걸리고 compile도 무척 많은 CPU를 사용하며 오래 걸린다는 점에 유의하십시요.

[ibm@centos01 openjdkathome]$ XUSE_NEW_BUILD_SYSTEM=true XBUILD=true ./obuildfactory/openjdk9/linux/standalone-job.sh
...
Creating jre jimage
Creating jdk jimage
WARNING: Using incubator modules: jdk.incubator.httpclient
WARNING: Using incubator modules: jdk.incubator.httpclient
Stopping sjavac server
Finished building target 'images' in configuration 'linux-x86-normal-server-release'
openjdk version "9-internal"
OpenJDK Runtime Environment (build 9-internal+0-adhoc.ibm.openjdk9)
OpenJDK 64-Bit Server VM (build 9-internal+0-adhoc.ibm.openjdk9, mixed mode)
openjdk version "9-internal"
OpenJDK Runtime Environment (build 9-internal+0-adhoc.ibm.openjdk9)
OpenJDK 64-Bit Server VM (build 9-internal+0-adhoc.ibm.openjdk9, mixed mode)
~/openjdkathome/sources/openjdk9/build/linux-x86-normal-server-release/images ~/openjdkathome
produced tarball files under /home/ibm/openjdkathome/OBF_DROP_DIR/openjdk9
-rw-rw-r--. 1 ibm ibm 337406797 May 14 10:36 /home/ibm/openjdkathome/OBF_DROP_DIR/openjdk9/jdk-ppc64le-b94-20180514.tar.bz2
-rw-rw-r--. 1 ibm ibm 188142592 May 14 10:37 /home/ibm/openjdkathome/OBF_DROP_DIR/openjdk9/jre-ppc64le-b94-20180514.tar.bz2
~/openjdkathome

생선된 tar ball은 아래 directory에 있습니다. JDK와 JRE가 각각 하나씩 만들어집니다.

[ibm@centos01 openjdkathome]$ ls -l OBF_DROP_DIR/openjdk9
total 513236
-rw-rw-r--. 1 ibm ibm 337406797 May 14 10:36 jdk-ppc64le-b94-20180514.tar.bz2
-rw-rw-r--. 1 ibm ibm 188142592 May 14 10:37 jre-ppc64le-b94-20180514.tar.bz2

우리는 여기서 JDK를 설치할 것입니다. 다음과 같이 /usr/local에 풀어놓고 JAVA_HOME 및 PATH를 설정해주시면 됩니다.

[ibm@centos01 openjdkathome]$ cd /usr/local

[ibm@centos01 local]$ sudo tar -jxvf ~/openjdkathome/OBF_DROP_DIR/openjdk9/jdk-ppc64le-b94-20180514.tar.bz2

[ibm@centos01 local]$ export JAVA_HOME=/usr/local/jdk
[ibm@centos01 local]$ export PATH=$JAVA_HOME/bin:/home/ibm/files/gradle-4.3/bin:$PATH

[ibm@centos01 local]$ java -fullversion
openjdk full version "9-internal+0-adhoc.ibm.openjdk9"

이제 open JFX의 source code를 받아옵니다. Mericurial의 hg 명령을 써서 가져오는데, 처음 몇 분 정도는 source를 전혀 못 가져오고 hang만 걸려 있는 것처럼 보이지만 한 10~20분 기다리니 결국은 받아오니 인내심을 가지시기 바랍니다. 또는 지난 번처럼 github에서 받아오셔도 됩니다. github에서 받아오는 것이 훨씬 빠릅니다.

[ibm@centos01 files]$ hg clone http://hg.openjdk.java.net/openjfx/jfx-dev/rt
destination directory: rt
requesting all changes
adding changesets
adding manifests
adding file changes
added 10923 changesets with 178749 changes to 85736 files
updating to branch default
31760 files updated, 0 files merged, 0 files removed, 0 files unresolved

[ibm@centos01 files]$ cd ../rt

[ibm@centos01 rt]$ ls -ltr
total 300
-rw-rw-r--. 1 ibm ibm 116 May 14 10:13 README
-rw-rw-r--. 1 ibm ibm 19274 May 14 10:13 LICENSE
-rw-rw-r--. 1 ibm ibm 1522 May 14 10:13 ASSEMBLY_EXCEPTION
-rw-rw-r--. 1 ibm ibm 2114 May 14 10:13 ADDITIONAL_LICENSE_INFO
drwxrwxr-x. 7 ibm ibm 102 May 14 10:13 apps
-rw-rw-r--. 1 ibm ibm 3166 May 14 10:13 build.properties
-rw-rw-r--. 1 ibm ibm 232809 May 14 10:13 build.gradle
drwxrwxr-x. 5 ibm ibm 60 May 14 10:13 dependencies
drwxrwxr-x. 4 ibm ibm 272 May 14 10:13 buildSrc
drwxrwxr-x. 26 ibm ibm 4096 May 14 10:13 netbeans
-rw-rw-r--. 1 ibm ibm 2176 May 14 10:13 gradlew.bat
-rw-rw-r--. 1 ibm ibm 5296 May 14 10:13 gradlew
-rw-rw-r--. 1 ibm ibm 13404 May 14 10:13 gradle.properties.template
drwxrwxr-x. 4 ibm ibm 34 May 14 10:13 gradle
drwxrwxr-x. 2 ibm ibm 49 May 14 10:13 doc-files
-rw-rw-r--. 1 ibm ibm 2275 May 14 10:13 settings.gradle
drwxrwxr-x. 6 ibm ibm 123 May 14 10:13 tests
drwxrwxr-x. 12 ibm ibm 215 May 14 10:13 modules
drwxrwxr-x. 4 ibm ibm 36 May 14 10:13 tools

지난번 posting에서처럼, 여기서도 gradle에게 ppc64le도 지원하는 아키텍처라고 인식시키도록 다음 file을 살짝 수정해줍니다. 그러지 않을 경우 "FAIL: Unknown and unsupported build architecture: ppc64le" error를 만나시게 됩니다.

[ibm@centos01 rt]$ vi build.gradle
...
//} else if (IS_LINUX && OS_ARCH != "i386" && OS_ARCH != "amd64") {
} else if (IS_LINUX && OS_ARCH != "ppc64le" && OS_ARCH != "amd64") {
fail("Unknown and unsupported build architecture: $OS_ARCH")
}

이제 grale을 수행해 보시면 잘 됩니다.

[ibm@centos01 rt]$ gradle
...
:zipSourceFilesStandaloneLinux
:buildModules
:createTestArgfilesLinux
:sdkLinux
:sdk

BUILD SUCCESSFUL in 2m 31s
111 actionable tasks: 111 executed

Build된 SDK는 build/modular-sdk 밑에 들어있습니다.

[ibm@centos01 rt]$ ls build/modular-sdk
make modules modules_conf modules_legal modules_libs modules_src

다음과 같이 이 SDK가 제대로 build된 것인지 테스트해보겠습니다.

[ibm@centos01 rt]$ gradle :base:test
...
:sdk
:base:compileShimsJava UP-TO-DATE
:base:processShimsResources NO-SOURCE
:base:copyGeneratedShims UP-TO-DATE
:base:compileTestJava UP-TO-DATE
:base:processTestResources NO-SOURCE
:base:testClasses UP-TO-DATE
:base:test UP-TO-DATE

BUILD SUCCESSFUL in 10s
115 actionable tasks: 8 executed, 107 up-to-date

잘 됩니다.

[ibm@centos01 rt]$ du -sm .
1440 .

이제 이 rt directory를 tar로 돌돌 말면 됩니다.

[ibm@centos01 rt]$ cd ..

[ibm@centos01 files]$ tar -zcf openjfs.tgz rt

이 openjfs.tgz와 저 위에서 build한 jdk-ppc64le-b94-20180514.tar.bz2, jre-ppc64le-b94-20180514.tar.bz2은 아래 google drive에 올려두겠습니다.

openjfs.tgz https://drive.google.com/open?id=1DYj_ZqzXsqSGNZ5cOuJVl9Dn9apJMCoo

jdk-ppc64le-b94-20180514.tar.bz2 https://drive.google.com/open?id=17AVhSwUlPMLv7q975HpBE_wUc5bf-FdY

jre-ppc64le-b94-20180514.tar.bz2 https://drive.google.com/open?id=1On0UVyYOocDyImWxl28mDB2kopzsCVcE

2018년 1월 19일 금요일

AC922 Redhat 환경에서 source code로부터 caffe build하기

AC922 Redhat 환경에서는 아직은 정식으로 PowerAI가 full 지원되지 않으며, 이는 2018년 2Q로 예정되어 있습니다. 그러나 source code로부터 빌드하는 것은 언제나 하기 나름입니다.

지난 포스팅에서는 AC922에서 Tensorflow 1.4.1을 빌드하는 것을 보여드렸는데, 이번에는 caffe (물론 bvlc-caffe)를 빌드합니다. 이번에는 IBM 이보란 과장께서 수고해주셨습니다. 본문은 아래 이보란 과장이 운영하는 블로그를 click 하십시요.

http://shareithw.blogspot.kr/2018/01/bvlc-caffe-rhel-power9-ppc64le.html