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

          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

          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

          0      64.25

          3       0.00

1

          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


2020년 12월 8일 화요일

IBM PowerAI (Watson ML Community Edition)이 설치된 Ubuntu ppc64le 기반의 docker image 만들기

 


먼저 다음 링크를 참조하여 ppc64le (IBM POWER9) nvidia-docker2 환경에서 Ubuntu 기반의 docker image를 만듭니다.  


http://hwengineer.blogspot.com/2019/05/ppc64le-ibm-power9-nvidia-docker2.html


참고로 ppc64le (IBM POWER9)에서의 CUDA 설치는 NVIDIA CUDA download page의 안내와 같이 아래처럼 진행하시면 됩니다.


# wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/ppc64el/cuda-repo-ubuntu1804_10.1.105-1_ppc64el.deb

# dpkg -i cuda-repo-ubuntu1804_10.1.105-1_ppc64el.deb

# apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/ppc64el/7fa2af80.pub

# apt-get update

# apt-get install cuda



또는 이미 만들어둔 docker image를 다음과 같이 pull 해와도 됩니다.


# docker pull bsyu/ubuntu18.04_cuda10-1_ppc64le:v0.1


이렇게 pull 받아온 docker image를 확인합니다.


root@unigpu:/files/docker# docker images

REPOSITORY                          TAG                 IMAGE ID            CREATED             SIZE

bsyu/ubuntu18.04_cuda10-1_ppc64le   v0.1                ef8dd4d654e7        2 hours ago         6.33GB

ubuntu                              18.04               ecc8dc2e4170        4 weeks ago         106MB


이 image를 다음과 같이 구동합니다.  


root@unigpu:/files/docker# docker run --runtime=nvidia -ti --rm bsyu/ubuntu18.04_cuda10-1_ppc64lel:v0.1 bash


이제 그 image 속에서 다음과 같이 IBM PowerAI (IBM Watson ML Community Edition)을 설치합니다.  이는 IBM이 마련한 conda channel을 등록하고 거기에서 conda install 명령을 수행하는 방식으로 설치됩니다.


# conda config --prepend channels https://public.dhe.ibm.com/ibmdl/export/pub/software/server/ibm-ai/conda/


# conda create --name wmlce_env python=3.6


# conda activate wmlce_env


# apt-get install openssh-server


# conda install powerai     


위와 같이 conda install powerai 명령을 내리면 tensorflow 뿐만 아니라 caffe, pytorch 등이 모두 설치됩니다.  가령 Tensorflow 1.14만 설치하고자 한다면 위 명령 대신 conda install tensorflow=1.14를 수행하시면 됩니다.


powerai 전체 package 설치는 network 사정에 따라 1~2시간이 걸리기도 합니다.  설치가 완료되면 다음과 같이 docker commit하여 docker image를 저장합니다.


# docker ps -a

CONTAINER ID        IMAGE                                   COMMAND             CREATED             STATUS              PORTS               NAMES

45fb663f025c        bsyu/ubuntu18.04_cuda10-1_ppc64le:v0.1   "bash"              42 seconds ago      Up 39 seconds                           elastic_gates


이어서 v0.2 등의 새로운 tag로 commit 하시면 됩니다.


[root@ac922 docker]# docker commit 45fb663f025c bsyu/ubuntu18.04_cuda10-1_ppc64le:v0.2



아래는 그렇게 만들어진 docker image들의 사용예입니다.   제가 만든 그런 image들은 https://hub.docker.com/u/bsyu 에 올려져 있습니다.



root@unigpu:~# docker run --runtime=nvidia -ti --rm bsyu/ubuntu18.04_cuda10-1_tf1.15_pytorch1.2_ppc64le:latest 


(wmlce_env) root@bdbf11e90094:/# python

Python 3.6.10 |Anaconda, Inc.| (default, Mar 26 2020, 00:22:27)

[GCC 7.3.0] on linux

Type "help", "copyright", "credits" or "license" for more information.


>>> import torch


>>> import tensorflow as tf

2020-05-29 04:53:09.637141: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcudart.so.10.1


>>> sess=tf.Session()

2020-05-29 04:53:20.795027: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcuda.so.1

2020-05-29 04:53:20.825918: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1639] Found device 0 with properties:

name: Tesla V100-SXM2-16GB major: 7 minor: 0 memoryClockRate(GHz): 1.53

pciBusID: 0004:04:00.0

2020-05-29 04:53:20.827162: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1639] Found device 1 with properties:

name: Tesla V100-SXM2-16GB major: 7 minor: 0 memoryClockRate(GHz): 1.53

pciBusID: 0004:05:00.0

2020-05-29 04:53:20.828421: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1639] Found device 2 with properties:

name: Tesla V100-SXM2-16GB major: 7 minor: 0 memoryClockRate(GHz): 1.53

pciBusID: 0035:03:00.0

2020-05-29 04:53:20.829655: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1639] Found device 3 with properties:

name: Tesla V100-SXM2-16GB major: 7 minor: 0 memoryClockRate(GHz): 1.53

pciBusID: 0035:04:00.0

2020년 10월 27일 화요일

IBM POWER9 (ppc64le) Redhat 7에서 Spectrum Scale (GPFS) v5 구성하기

 


여기서의 설정은 gw(2.1.1.1) 서버를 1대 뿐인 GPFS 서버로, 그리고 2대의 서버 tac1과 tac2 (각각 2.1.1.3, 2.1.1.4)를 GPFS client 노드로 등록하는 것입니다.  즉 GPFS의 물리적 disk가 직접 연결되는 것은 gw 서버이고, tac1과 tac2 서버는 gw 서버가 보내주는 GPFS filesystem을 NSD (network storage device) 형태로 network을 통해서 받게 됩니다.


먼저 모든 서버에서 firewalld를 disable합니다.  이와 함께 각 서버 간에 passwd 없이 ssh가 가능하도록 미리 설정해둡니다.


[root@gw ~]# systemctl stop firewalld


[root@gw ~]# systemctl disable firewalld


여기서는 GPFS (새이름 SpectrumScale) installer를 이용하여 설치하겠습니다.  GPFS v5부터는 ansible을 이용하여 1대에서만 설치하면 다른 cluster node들에게도 자동으로 설치가 되어 편합니다.  먼저 install 파일을 수행하면 self-extraction이 시작되며 파일들이 생성됩니다.


[root@gw SW]# ./Spectrum_Scale_Advanced-5.0.4.0-ppc64LE-Linux-install

Extracting Product RPMs to /usr/lpp/mmfs/5.0.4.0 ...

tail -n +641 ./Spectrum_Scale_Advanced-5.0.4.0-ppc64LE-Linux-install | tar -C /usr/lpp/mmfs/5.0.4.0 --wildcards -xvz  installer gpfs_rpms/rhel/rhel7 hdfs_debs/ubuntu16/hdfs_3.1.0.x hdfs_rpms/rhel7/hdfs_2.7.3.x hdfs_rpms/rhel7/hdfs_3.0.0.x hdfs_rpms/rhel7/hdfs_3.1.0.x zimon_debs/ubuntu/ubuntu16 ganesha_rpms/rhel7 ganesha_rpms/rhel8 gpfs_debs/ubuntu16 gpfs_rpms/sles12 object_rpms/rhel7 smb_rpms/rhel7 smb_rpms/rhel8 tools/repo zimon_debs/ubuntu16 zimon_rpms/rhel7 zimon_rpms/rhel8 zimon_rpms/sles12 zimon_rpms/sles15 gpfs_debs gpfs_rpms manifest 1> /dev/null

   - installer

   - gpfs_rpms/rhel/rhel7

   - hdfs_debs/ubuntu16/hdfs_3.1.0.x

   - hdfs_rpms/rhel7/hdfs_2.7.3.x

...

   - gpfs_debs

   - gpfs_rpms

   - manifest


Removing License Acceptance Process Tool from /usr/lpp/mmfs/5.0.4.0 ...

rm -rf  /usr/lpp/mmfs/5.0.4.0/LAP_HOME /usr/lpp/mmfs/5.0.4.0/LA_HOME


Removing JRE from /usr/lpp/mmfs/5.0.4.0 ...

rm -rf /usr/lpp/mmfs/5.0.4.0/ibm-java*tgz


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

Product packages successfully extracted to /usr/lpp/mmfs/5.0.4.0


   Cluster installation and protocol deployment

      To install a cluster or deploy protocols with the Spectrum Scale Install Toolkit:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale -h

      To install a cluster manually:  Use the gpfs packages located within /usr/lpp/mmfs/5.0.4.0/gpfs_<rpms/debs>


      To upgrade an existing cluster using the Spectrum Scale Install Toolkit:

      1) Copy your old clusterdefinition.txt file to the new /usr/lpp/mmfs/5.0.4.0/installer/configuration/ location

      2) Review and update the config:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale config update

      3) (Optional) Update the toolkit to reflect the current cluster config:

         /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale config populate -N <node>

      4) Run the upgrade:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale upgrade -h


      To add nodes to an existing cluster using the Spectrum Scale Install Toolkit:

      1) Add nodes to the clusterdefinition.txt file:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale node add -h

      2) Install GPFS on the new nodes:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale install -h

      3) Deploy protocols on the new nodes:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale deploy -h


      To add NSDs or file systems to an existing cluster using the Spectrum Scale Install Toolkit:

      1) Add nsds and/or filesystems with:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale nsd add -h

      2) Install the NSDs:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale install -h

      3) Deploy the new file system:  /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale deploy -h


      To update the toolkit to reflect the current cluster config examples:

         /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale config populate -N <node>

      1) Manual updates outside of the install toolkit

      2) Sync the current cluster state to the install toolkit prior to upgrade

      3) Switching from a manually managed cluster to the install toolkit


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

To get up and running quickly, visit our wiki for an IBM Spectrum Scale Protocols Quick Overview:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General%20Parallel%20File%20System%20%28GPFS%29/page/Protocols%20Quick%20Overview%20for%20IBM%20Spectrum%20Scale

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



먼저 아래와 같이 spectrumscale 명령으로 gw 서버, 즉 2.1.1.5를 installer 서버로 지정합니다.  


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale setup -s 2.1.1.5


이어서 gw 서버를 manager node이자 admin node로 지정합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale node add 2.1.1.5 -m -n -a

[ INFO  ] Adding node gw as a GPFS node.

[ INFO  ] Adding node gw as a manager node.

[ INFO  ] Adding node gw as an NSD server.

[ INFO  ] Configuration updated.

[ INFO  ] Tip :If all node designations are complete, add NSDs to your cluster definition and define required filessytems:./spectrumscale nsd add <device> -p <primary node> -s <secondary node> -fs <file system>

[ INFO  ] Setting gw as an admin node.

[ INFO  ] Configuration updated.

[ INFO  ] Tip : Designate protocol or nsd nodes in your environment to use during install:./spectrumscale node add <node> -p -n



각 node들을 quorum node로 등록합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale node add 2.1.1.3 -q


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale node add 2.1.1.4 -q


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale node add 2.1.1.5 -q

[ INFO  ] Adding node gwp as a quorum node.



node list를 확인합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale node list

[ INFO  ] List of nodes in current configuration:

[ INFO  ] [Installer Node]

[ INFO  ] 2.1.1.5

[ INFO  ]

[ INFO  ] [Cluster Details]

[ INFO  ] No cluster name configured

[ INFO  ] Setup Type: Spectrum Scale

[ INFO  ]

[ INFO  ] [Extended Features]

[ INFO  ] File Audit logging     : Disabled

[ INFO  ] Watch folder           : Disabled

[ INFO  ] Management GUI         : Disabled

[ INFO  ] Performance Monitoring : Enabled

[ INFO  ] Callhome               : Enabled

[ INFO  ]

[ INFO  ] GPFS  Admin  Quorum  Manager   NSD   Protocol  Callhome   OS   Arch

[ INFO  ] Node   Node   Node     Node   Server   Node     Server

[ INFO  ] gw      X       X       X       X                       rhel7  ppc64le

[ INFO  ] tac1p           X                                       rhel7  ppc64le

[ INFO  ] tac2p           X                                       rhel7  ppc64le

[ INFO  ]

[ INFO  ] [Export IP address]

[ INFO  ] No export IP addresses configured



sdc와 sdd를 nsd로 등록합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale nsd add /dev/sdc -p 2.1.1.5 --name data_nsd -fs data


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale nsd add /dev/sdd -p 2.1.1.5 --name backup_nsd -fs backup


nsd를 확인합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale nsd list

[ INFO  ] Name       FS     Size(GB) Usage   FG Pool    Device   Servers

[ INFO  ] data_nsd   data   400      Default 1  Default /dev/sdc [gwp]

[ INFO  ] backup_nsd backup 400      Default 1  Default /dev/sdd [gwp]


filesystem을 확인합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale filesystem list

[ INFO  ] Name   BlockSize   Mountpoint   NSDs Assigned  Default Data Replicas     Max Data Replicas     Default Metadata Replicas     Max Metadata Replicas

[ INFO  ] data   Default (4M)/ibm/data    1              1                         2                     1                             2

[ INFO  ] backup Default (4M)/ibm/backup  1              1                         2                     1                             2

[ INFO  ]



GPFS cluster를 정의합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale config gpfs -c tac_gpfs

[ INFO  ] Setting GPFS cluster name to tac_gpfs


다른 node들에게의 통신은 ssh와 scp를 이용하는 것으로 지정합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale config gpfs -r /usr/bin/ssh

[ INFO  ] Setting Remote shell command to /usr/bin/ssh


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale config gpfs -rc /usr/bin/scp

[ INFO  ] Setting Remote file copy command to /usr/bin/scp


확인합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale config gpfs --list

[ INFO  ] Current settings are as follows:

[ INFO  ] GPFS cluster name is tac_gpfs.

[ INFO  ] GPFS profile is default.

[ INFO  ] Remote shell command is /usr/bin/ssh.

[ INFO  ] Remote file copy command is /usr/bin/scp.

[ WARN  ] No value for GPFS Daemon communication port range in clusterdefinition file.



기본으로 GPFS 서버는 장애 발생시 IBM으로 연락하는 callhome 기능이 있습니다.  Internet에 연결된 노드가 아니므로 disable합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale callhome disable

[ INFO  ] Disabling the callhome.

[ INFO  ] Configuration updated.


이제 install 준비가 되었습니다.  Install 하기 전에 precheck을 수행합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale install -pr

[ INFO  ] Logging to file: /usr/lpp/mmfs/5.0.4.0/installer/logs/INSTALL-PRECHECK-23-10-2020_21:13:23.log

[ INFO  ] Validating configuration

...

[ INFO  ] The install toolkit will not configure call home as it is disabled. To enable call home, use the following CLI command: ./spectrumscale callhome enable

[ INFO  ] Pre-check successful for install.

[ INFO  ] Tip : ./spectrumscale install


이상 없으면 install을 수행합니다.  이때 gw 뿐만 아니라 tac1과 tac2에도 GPFS가 설치됩니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale install

...

[ INFO  ] GPFS active on all nodes

[ INFO  ] GPFS ACTIVE

[ INFO  ] Checking state of NSDs

[ INFO  ] NSDs ACTIVE

[ INFO  ] Checking state of Performance Monitoring

[ INFO  ] Running Performance Monitoring post-install checks

[ INFO  ] pmcollector running on all nodes

[ INFO  ] pmsensors running on all nodes

[ INFO  ] Performance Monitoring ACTIVE

[ INFO  ] SUCCESS

[ INFO  ] All services running

[ INFO  ] StanzaFile and NodeDesc file for NSD, filesystem, and cluster setup have been saved to /usr/lpp/mmfs folder on node: gwp

[ INFO  ] Installation successful. 3 GPFS nodes active in cluster tac_gpfs.tac1p. Completed in 2 minutes 52 seconds.

[ INFO  ] Tip :If all node designations and any required protocol configurations are complete, proceed to check the deploy configuration:./spectrumscale deploy --precheck



참고로 여기서 아래와 같은 error가 나는 경우는 전에 이미 GPFS NSD로 사용된 disk이기 때문입니다.  


[ FATAL ] gwp failure whilst: Creating NSDs  (SS16)

[ WARN  ] SUGGESTED ACTION(S):

[ WARN  ] Review your NSD device configuration in configuration/clusterdefinition.txt

[ WARN  ] Ensure all disks are not damaged and can be written to.

[ FATAL ] FAILURE REASON(s) for gwp:

[ FATAL ] gwp ---- Begin output of /usr/lpp/mmfs/bin/mmcrnsd -F /usr/lpp/mmfs/StanzaFile  ----

[ FATAL ] gwp STDOUT: mmcrnsd: Processing disk sdc

[ FATAL ] gwp mmcrnsd: Processing disk sdd

[ FATAL ] gwp STDERR: mmcrnsd: Disk device sdc refers to an existing NSD

[ FATAL ] gwp mmcrnsd: Disk device sdd refers to an existing NSD

[ FATAL ] gwp mmcrnsd: Command failed. Examine previous error messages to determine cause.

[ FATAL ] gwp ---- End output of /usr/lpp/mmfs/bin/mmcrnsd -F /usr/lpp/mmfs/StanzaFile  ----

[ INFO  ] Detailed error log: /usr/lpp/mmfs/5.0.4.0/installer/logs/INSTALL-23-10-2020_21:20:05.log

[ FATAL ] Installation failed on one or more nodes. Check the log for more details.


이건 다음과 같이 disk 앞부분 약간을 덮어쓰면 됩니다.


[root@gw SW]# dd if=/dev/zero of=/dev/sdc bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 0.0736579 s, 1.4 GB/s


[root@gw SW]# dd if=/dev/zero of=/dev/sdd bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 0.0737598 s, 1.4 GB/s



이제 각 node 상태를 check 합니다.  


[root@gw SW]# mmgetstate -a


 Node number  Node name        GPFS state

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

       1      tac1p            active

       2      tac2p            active

       3      gwp              active


nsd 상태를 check 합니다.  그런데 GPFS filesystem 정의가 (free disk)로 빠져 있는 것을 보실 수 있습니다.


[root@gw SW]# mmlsnsd


 File system   Disk name    NSD servers

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

 (free disk)   backup_nsd   gwp

 (free disk)   data_nsd     gwp


spectrumscale filesystem list 명령으로 다시 GPFS filesystem 상태를 보면 거기엔 정보가 들어가 있습니다.  다만 mount point가 /ibm/data 이런 식으로 잘못 되어 있네요.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale filesystem list

[ INFO  ] Name   BlockSize   Mountpoint   NSDs Assigned  Default Data Replicas     Max Data Replicas     Default Metadata Replicas     Max Metadata Replicas

[ INFO  ] data   Default (4M)/ibm/data    1              1                         2                     1                             2

[ INFO  ] backup Default (4M)/ibm/backup  1              1                         2                     1                             2

[ INFO  ]


잘못된 mount point들을 제대로 수정합니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale filesystem modify data -m /data

[ INFO  ] The data filesystem will be mounted at /data on all nodes.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale filesystem modify backup -m /backup

[ INFO  ] The backup filesystem will be mounted at /backup on all nodes.


확인합니다.  그러나 여전히 mount는 되지 않습니다.


[root@gw SW]# /usr/lpp/mmfs/5.0.4.0/installer/spectrumscale filesystem list

[ INFO  ] Name   BlockSize   Mountpoint   NSDs Assigned  Default Data Replicas     Max Data Replicas     Default Metadata Replicas     Max Metadata Replicas

[ INFO  ] data   Default (4M)/data        1              1                         2                     1                             2

[ INFO  ] backup Default (4M)/backup      1              1                         2                     1                             2

[ INFO  ]


이를 수정하기 위해 GPFS fileystem 설정은 예전 방식, 즉 mmcrnsd와 mmcrfs 명령을 쓰겠습니다.  먼저 disk description 파일을 아래와 같이 만듭니다.


[root@gw ~]# vi /home/SW/gpfs/disk.desc1

/dev/sdc:gwp::dataAndMetadata:1:nsd_data


[root@gw ~]# vi /home/SW/gpfs/disk.desc2

/dev/sdd:gwp::dataAndMetadata:1:nsd_backup


그리고 예전의 NSD 포맷을 지우기 위해 sdc와 sdd에 아래와 같이 dd로 overwrite를 합니다.


[root@gw ~]# dd if=/dev/zero of=/dev/sdc bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 0.0130229 s, 8.1 GB/s


[root@gw ~]# dd if=/dev/zero of=/dev/sdd bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 0.0128207 s, 8.2 GB/s


mmcrnsd 명령과 mmcrfs 명령을 수행하여 NSD와 GPFS filesystem을 만듭니다.


[root@gw ~]# mmcrnsd -F /home/SW/gpfs/disk.desc1


[root@gw ~]# mmcrnsd -F /home/SW/gpfs/disk.desc2


[root@gw ~]# mmcrfs /data /dev/nsd_data -F /home/SW/gpfs/disk.desc1


The following disks of nsd_data will be formatted on node gw:

    nsd_data: size 409600 MB

Formatting file system ...

Disks up to size 3.18 TB can be added to storage pool system.

Creating Inode File

Creating Allocation Maps

Creating Log Files

Clearing Inode Allocation Map

Clearing Block Allocation Map

Formatting Allocation Map for storage pool system

Completed creation of file system /dev/nsd_data.

mmcrfs: Propagating the cluster configuration data to all

  affected nodes.  This is an asynchronous process.



[root@gw ~]# mmcrfs /backup /dev/nsd_backup -F /home/SW/gpfs/disk.desc2


The following disks of nsd_backup will be formatted on node gw:

    nsd_backup: size 409600 MB

Formatting file system ...

Disks up to size 3.18 TB can be added to storage pool system.

Creating Inode File

Creating Allocation Maps

Creating Log Files

Clearing Inode Allocation Map

Clearing Block Allocation Map

Formatting Allocation Map for storage pool system

Completed creation of file system /dev/nsd_backup.

mmcrfs: Propagating the cluster configuration data to all

  affected nodes.  This is an asynchronous process.


이제 모든 node에서 mount 해봅니다.


[root@gw ~]# mmmount all -a

Sat Oct 24 09:45:43 KST 2020: mmmount: Mounting file systems ...


[root@gw ~]# df -h

Filesystem      Size  Used Avail Use% Mounted on

devtmpfs        1.7G     0  1.7G   0% /dev

tmpfs           1.8G   18M  1.8G   1% /dev/shm

tmpfs           1.8G   96M  1.7G   6% /run

tmpfs           1.8G     0  1.8G   0% /sys/fs/cgroup

/dev/sda5        50G  5.4G   45G  11% /

/dev/sda6       345G  8.6G  337G   3% /home

/dev/sda2      1014M  178M  837M  18% /boot

tmpfs           355M     0  355M   0% /run/user/0

/dev/sr0        3.4G  3.4G     0 100% /home/cdrom

nsd_backup      400G  2.8G  398G   1% /backup

nsd_data        400G  2.8G  398G   1% /data


테스트를 위해 /data 밑에 /etc/hosts 파일을 copy해 둡니다.


[root@gw ~]# cp /etc/hosts /data


[root@gw ~]# ls -l /data

total 1

-rw-r--r--. 1 root root 298 Oct 24 09:49 hosts



Client node들에서도 잘 mount 되었는지 확인합니다.  그리고 아까 copy해둔 hosts 파일이 있는 확인합니다.


[root@gw ~]# ssh tac1

Last login: Sat Oct 24 09:33:46 2020 from gwp


[root@tac1 ~]# df -h

Filesystem      Size  Used Avail Use% Mounted on

devtmpfs         28G     0   28G   0% /dev

tmpfs            28G     0   28G   0% /dev/shm

tmpfs            28G   15M   28G   1% /run

tmpfs            28G     0   28G   0% /sys/fs/cgroup

/dev/sda5        50G  3.3G   47G   7% /

/dev/sda6       321G  2.8G  319G   1% /home

/dev/sda2      1014M  178M  837M  18% /boot

tmpfs           5.5G     0  5.5G   0% /run/user/0

nsd_data        400G  2.8G  398G   1% /data

nsd_backup      400G  2.8G  398G   1% /backup


[root@tac1 ~]# ls -l /data

total 1

-rw-r--r--. 1 root root 298 Oct 24 09:49 hosts




[root@gw ~]# ssh tac2

Last login: Sat Oct 24 09:33:46 2020 from gwp


[root@tac2 ~]# df -h

Filesystem      Size  Used Avail Use% Mounted on

devtmpfs         28G     0   28G   0% /dev

tmpfs            28G     0   28G   0% /dev/shm

tmpfs            28G   15M   28G   1% /run

tmpfs            28G     0   28G   0% /sys/fs/cgroup

/dev/sda5        50G  3.2G   47G   7% /

/dev/sda6       321G  3.3G  318G   2% /home

/dev/sda2      1014M  178M  837M  18% /boot

tmpfs           5.5G     0  5.5G   0% /run/user/0

nsd_backup      400G  2.8G  398G   1% /backup

nsd_data        400G  2.8G  398G   1% /data



[root@tac2 ~]# ls -l /data

total 1

-rw-r--r--. 1 root root 298 Oct 24 09:49 hosts





참고로 어떤 disk가 GPFS nsd인지는 fdisk 명령으로 아래와 같이 확인하실 수 있습니다.  fdisk -l 로 볼 때, 아래와 같이 IBM General Par GPFS라고 나오는 것이 GPFS nsd 입니다.



[root@tac1 ~]# fdisk -l | grep sd

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 429.5 GB, 429496729600 bytes, 838860800 sectors

/dev/sda1   *        2048       10239        4096   41  PPC PReP Boot

/dev/sda2           10240     2107391     1048576   83  Linux

/dev/sda3         2107392    60829695    29361152   82  Linux swap / Solaris

/dev/sda4        60829696   838860799   389015552    5  Extended

/dev/sda5        60831744   165689343    52428800   83  Linux

/dev/sda6       165691392   838860799   336584704   83  Linux

Disk /dev/sdb: 429.5 GB, 429496729600 bytes, 838860800 sectors

Disk /dev/sdc: 429.5 GB, 429496729600 bytes, 838860800 sectors

Disk /dev/sdd: 429.5 GB, 429496729600 bytes, 838860800 sectors

Disk /dev/sde: 429.5 GB, 429496729600 bytes, 838860800 sectors

Disk /dev/sdf: 429.5 GB, 429496729600 bytes, 838860800 sectors

Disk /dev/sdg: 429.5 GB, 429496729600 bytes, 838860800 sectors



[root@tac1 ~]# fdisk -l /dev/sdb

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.


Disk /dev/sdb: 429.5 GB, 429496729600 bytes, 838860800 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: gpt

Disk identifier: 236CE033-C570-41CC-8D2E-E20E6F494C38



#         Start          End    Size  Type            Name

 1           48    838860751    400G  IBM General Par GPFS:



[root@tac1 ~]# fdisk -l /dev/sdc

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.


Disk /dev/sdc: 429.5 GB, 429496729600 bytes, 838860800 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: gpt

Disk identifier: 507A299C-8E96-49E2-8C25-9D051BC9B935



#         Start          End    Size  Type            Name

 1           48    838860751    400G  IBM General Par GPFS:



일반 disk는 아래와 같이 평범하게 나옵니다.


[root@tac1 ~]# fdisk -l /dev/sdd


Disk /dev/sdd: 429.5 GB, 429496729600 bytes, 838860800 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes



IBM POWER9 Redhat 7에서 Redhat HA Cluster 구성하는 방법

 


Redhat HA cluster를 IBM POWER9 (ppc64le) 기반의 Redhat 7에서 설치하는 방법입니다.


먼저 firewalld를 stop 시킵니다.


[root@ha1 ~]# systemctl stop firewalld


[root@ha1 ~]# systemctl disable firewalld


아래의 package들을 설치합니다.  이건 Redhat OS DVD에는 없고 별도의 yum repository에 들어있습니다.  ppc64le의 경우엔 rhel-ha-for-rhel-7-server-for-power-le-rpms 라는 yum repo에 있습니다.


[root@ha1 ~]# yum install pcs fence-agents-all


설치하면 hacluster라는 user가 자동 생성되는데 여기에 passwd를지정해줘야 합니다.


[root@ha1 ~]# passwd hacluster


그리고 pcsd daemon을 start 합니다.  Reboot 후에도 자동 start 되도록 enable도 합니다.


[root@ha1 ~]# systemctl start pcsd.service


[root@ha1 ~]# systemctl enable pcsd.service


참여할 node에 아래와 같이 인증 작업을 합니다.


[root@ha1 ~]# pcs cluster auth ha1 ha2

Username: hacluster

Password:

ha1: Authorized

ha2: Authorized


간단히 아래와 같이 corosysnc.conf 파일을 만듭니다.  ha1, ha2 노드는 물론 /etc/hosts에 등록된 IP 주소입니다.


[root@ha1 ~]# vi /etc/corosync/corosync.conf

totem {

version: 2

secauth: off

cluster_name: tibero_cluster

transport: udpu

}


nodelist {

  node {

        ring0_addr: ha1

        nodeid: 1

       }

  node {

        ring0_addr: ha2

        nodeid: 2

       }

}


quorum {

provider: corosync_votequorum

two_node: 1

}


logging {

to_syslog: yes

}


Cluster를 전체 node에서 enable합니다.


[root@ha1 ~]# pcs cluster enable --all

ha1: Cluster Enabled

ha2: Cluster Enabled


다음과 같이 cluster start 합니다.


[root@ha1 ~]# pcs cluster start --all

ha1: Starting Cluster (corosync)...

ha2: Starting Cluster (corosync)...

ha1: Starting Cluster (pacemaker)...

ha2: Starting Cluster (pacemaker)...



상태 확인해봅니다.


[root@ha1 ~]# pcs cluster status

Cluster Status:

 Stack: unknown

 Current DC: NONE

 Last updated: Mon Oct 26 10:14:59 2020

 Last change: Mon Oct 26 10:14:55 2020 by hacluster via crmd on ha1

 2 nodes configured

 0 resource instances configured


PCSD Status:

  ha1: Online

  ha2: Online


이때 ha2 노드에 가보면 corosysnc.conf 파일은 없습니다.   


[root@ha2 ~]# ls -l /etc/corosync/

total 12

-rw-r--r--. 1 root root 2881 Jun  5 23:10 corosync.conf.example

-rw-r--r--. 1 root root  767 Jun  5 23:10 corosync.conf.example.udpu

-rw-r--r--. 1 root root 3278 Jun  5 23:10 corosync.xml.example

drwxr-xr-x. 2 root root    6 Jun  5 23:10 uidgid.d


이걸 ha2에서 생성시키려면 cluster를 sync하면 됩니다.


[root@ha1 ~]# pcs cluster sync

ha1: Succeeded

ha2: Succeeded


생성된 것을 확인하실 수 있습니다.


[root@ha2 ~]# ls -l /etc/corosync/

total 16

-rw-r--r--. 1 root root  295 Oct 26 10:17 corosync.conf

-rw-r--r--. 1 root root 2881 Jun  5 23:10 corosync.conf.example

-rw-r--r--. 1 root root  767 Jun  5 23:10 corosync.conf.example.udpu

-rw-r--r--. 1 root root 3278 Jun  5 23:10 corosync.xml.example

drwxr-xr-x. 2 root root    6 Jun  5 23:10 uidgid.d



이제 cluster resource를 확인합니다.  당연히 아직 정의된 것이 없습니다.


[root@ha1 ~]# pcs resource show

NO resources configured



두 node 사이에서 failover 받을 cluster의 virtual IP를 아래와 같이 VirtualIP라는 resource ID 이름으로 등록합니다.   참고로 ha1은 10.1.1.1, ha2는 10.1.1.2이고 모두 eth1에 부여된 IP입니다.


[root@ha1 ~]# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=10.1.1.11 cidr_netmask=24 nic=eth1 op monitor interval=30s


[root@ha1 ~]# pcs resource enable VirtualIP


이제 다시 resource를 봅니다.


[root@ha1 ~]# pcs resource show

 VirtualIP      (ocf::heartbeat:IPaddr2):       Stopped


아직 VirtualIP가 stopped 상태인데, 이는 아직 STONITH가 enable 되어 있는 default 상태이기 때문입니다.  STONITH는 split-brain을 방지하기 위한 장치인데, 지금 당장은 disable 하겠습니다.


[root@ha1 ~]# pcs property set stonith-enabled=false


Verify를 해봅니다.  아무 메시지 없으면 통과입니다.


[root@ha1 ~]# crm_verify -L


이제 다시 status를 보면 VirtualIP가 살아 있는 것을 보실 수 있습니다.


[root@ha1 ~]# pcs status

Cluster name: tibero_cluster

Stack: corosync

Current DC: ha1 (version 1.1.23-1.el7-9acf116022) - partition with quorum

Last updated: Mon Oct 26 11:18:31 2020

Last change: Mon Oct 26 11:17:31 2020 by root via cibadmin on ha1


2 nodes configured

1 resource instance configured


Online: [ ha1 ha2 ]


Full list of resources:


 VirtualIP      (ocf::heartbeat:IPaddr2):       Started ha1


Daemon Status:

  corosync: active/enabled

  pacemaker: active/enabled

  pcsd: active/enabled



또 IP address를 보면 10.1.1.11이 eth1에 붙은 것도 보실 수 있습니다.


[root@ha1 ~]# ip a | grep 10.1.1

    inet 10.1.1.1/24 brd 10.1.1.255 scope global noprefixroute eth1

    inet 10.1.1.11/24 brd 10.1.1.255 scope global secondary eth1


다른 node에서 10.1.1.11 (havip)로 ping을 해보면 잘 됩니다.


[root@gw ~]# ping havip

PING havip (10.1.1.11) 56(84) bytes of data.

64 bytes from havip (10.1.1.11): icmp_seq=1 ttl=64 time=0.112 ms

64 bytes from havip (10.1.1.11): icmp_seq=2 ttl=64 time=0.040 ms


이 resource가 failover된 이후 죽었던 node가 되살아나면 원래의 node로 failback 하게 하려면 아래와 같이 합니다.


[root@ha1 ~]# pcs resource defaults resource-stickiness=100

Warning: Defaults do not apply to resources which override them with their own defined values


[root@ha1 ~]# pcs resource defaults

resource-stickiness=100


이제 sdb disk를 이용하여 LVM 작업을 합니다.  여기서는 /data와 /backup이 VirtualIP와 함께 ha1에 mount 되어 있다가 유사시 ha2로 failover 되도록 하고자 합니다.


[root@ha1 ~]# pvcreate /dev/sdb


[root@ha1 ~]# vgcreate datavg /dev/sdb


[root@ha1 ~]# lvcreate -L210000 -n datalv datavg


[root@ha1 ~]# lvcreate -L150000 -n backuplv datavg


[root@ha1 ~]# vgs

  VG     #PV #LV #SN Attr   VSize    VFree

  datavg   1   2   0 wz--n- <400.00g 48.43g


[root@ha1 ~]# lvs

  LV       VG     Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

  backuplv datavg -wi-a-----  146.48g                                           

  datalv   datavg -wi-a----- <205.08g         



[root@ha1 ~]# mkfs.ext4 /dev/datavg/datalv


[root@ha1 ~]# mkfs.ext4 /dev/datavg/backuplv



[root@ha1 ~]# mkdir /data

[root@ha1 ~]# mkdir /backup


[root@ha1 ~]# ssh ha2 mkdir /data

[root@ha1 ~]# ssh ha2 mkdir /backup


이제 이 VG와 filesystem들이 한쪽 node에만, 그것도 OS가 아니라 HA cluster (pacemaker)에 의해서만 mount 되도록 설정합니다.


[root@ha1 ~]# grep use_lvmetad /etc/lvm/lvm.conf

        use_lvmetad = 1


[root@ha1 ~]# lvmconf --enable-halvm --services --startstopservices


[root@ha1 ~]# grep use_lvmetad /etc/lvm/lvm.conf

    use_lvmetad = 0


[root@ha1 ~]# vgs --noheadings -o vg_name

  datavg


그리고 이 VG와 LV, filesystem을 pcs에 등록합니다.


[root@ha1 ~]# pcs resource create tibero_vg LVM volgrpname=datavg exclusive=true --group tiberogroup

Assumed agent name 'ocf:heartbeat:LVM' (deduced from 'LVM')


[root@ha1 ~]# pcs resource create tibero_data Filesystem device="/dev/datavg/datalv" directory="/data" fstype="ext4" --group tiberogroup

Assumed agent name 'ocf:heartbeat:Filesystem' (deduced from 'Filesystem')


[root@ha1 ~]# pcs resource create tibero_backup Filesystem device="/dev/datavg/backuplv" directory="/backup" fstype="ext4" --group tiberogroup

Assumed agent name 'ocf:heartbeat:Filesystem' (deduced from 'Filesystem')


[root@ha1 ~]# pcs resource update VirtualIP --group tiberogroup


그리고 VirtualIP가 항상 이 filesytem들과 함께 움직이도록 colocation constraint를 줍니다.


[root@ha1 ~]# pcs constraint colocation add tiberogroup with VirtualIP INFINITY


그리고 아래 내용은 두 node에서 모두 수행합니다.  ha2도 reboot해야 거기서 datavg 및 거기에 든 LV들이 인식됩니다.


[root@ha1 ~]# vi /etc/lvm/lvm.conf

...

 volume_list = [ ]

...


[root@ha1 ~]# dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)


[root@ha1 ~]# shutdown -r now



Reboot 이후 보면 VirtualIP나 /data, /backup filesystem이 모두 ha1에서 mount 되어 있는 것을 보실 수 있습니다.



[root@ha1 ~]# pcs status

Cluster name: tibero_cluster

Stack: corosync

Current DC: ha1 (version 1.1.23-1.el7-9acf116022) - partition with quorum

Last updated: Mon Oct 26 13:44:36 2020

Last change: Mon Oct 26 13:44:14 2020 by root via cibadmin on ha1


2 nodes configured

4 resource instances configured


Online: [ ha1 ha2 ]


Full list of resources:


 VirtualIP      (ocf::heartbeat:IPaddr2):       Started ha1

 Resource Group: tiberogroup

     tibero_vg  (ocf::heartbeat:LVM):   Started ha1

     tibero_data        (ocf::heartbeat:Filesystem):    Started ha1

     tibero_backup      (ocf::heartbeat:Filesystem):    Started ha1


Daemon Status:

  corosync: active/enabled

  pacemaker: active/enabled

  pcsd: active/enabled



ha1 노드를 죽여버리면 곧 VirtualIP와 filesystem들이 자동으로 ha2에 failover 되어 있는 것을 확인하실 수 있습니다.


[root@ha1 ~]# halt -f

Halting.


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


[root@ha2 ~]# df -h

Filesystem                   Size  Used Avail Use% Mounted on

devtmpfs                      28G     0   28G   0% /dev

tmpfs                         28G   58M   28G   1% /dev/shm

tmpfs                         28G   14M   28G   1% /run

tmpfs                         28G     0   28G   0% /sys/fs/cgroup

/dev/sda5                     50G  2.6G   48G   6% /

/dev/sda6                    321G  8.5G  313G   3% /home

/dev/sda2                   1014M  231M  784M  23% /boot

tmpfs                        5.5G     0  5.5G   0% /run/user/0

/dev/mapper/datavg-datalv    202G   61M  192G   1% /data

/dev/mapper/datavg-backuplv  145G   61M  137G   1% /backup


[root@ha2 ~]# ip a | grep 10.1.1

    inet 10.1.1.2/24 brd 10.1.1.255 scope global noprefixroute eth1

    inet 10.1.1.11/24 brd 10.1.1.255 scope global secondary eth1



ha1이 죽은 상태에서의 status는 아래와 같이 나옵니다.


[root@ha2 ~]# pcs status

Cluster name: tibero_cluster

Stack: corosync

Current DC: ha2 (version 1.1.23-1.el7-9acf116022) - partition with quorum

Last updated: Mon Oct 26 13:48:49 2020

Last change: Mon Oct 26 13:47:18 2020 by root via cibadmin on ha1


2 nodes configured

4 resource instances configured


Online: [ ha2 ]

OFFLINE: [ ha1 ]


Full list of resources:


 VirtualIP      (ocf::heartbeat:IPaddr2):       Started ha2

 Resource Group: tiberogroup

     tibero_vg  (ocf::heartbeat:LVM):   Started ha2

     tibero_data        (ocf::heartbeat:Filesystem):    Started ha2

     tibero_backup      (ocf::heartbeat:Filesystem):    Started ha2


Daemon Status:

  corosync: active/enabled

  pacemaker: active/enabled

  pcsd: active/enabled


이 상태에서 pcs cluster를 stop 시키면 VirtualIP와 filesystem들이 모두 내려갑니다.


[root@ha2 ~]# pcs cluster stop --force

Stopping Cluster (pacemaker)...

Stopping Cluster (corosync)...



[root@ha2 ~]# df -h

Filesystem      Size  Used Avail Use% Mounted on

devtmpfs         28G     0   28G   0% /dev

tmpfs            28G     0   28G   0% /dev/shm

tmpfs            28G   14M   28G   1% /run

tmpfs            28G     0   28G   0% /sys/fs/cgroup

/dev/sda5        50G  2.6G   48G   6% /

/dev/sda6       321G  8.5G  313G   3% /home

/dev/sda2      1014M  231M  784M  23% /boot

tmpfs           5.5G     0  5.5G   0% /run/user/0



[root@ha2 ~]# ip a | grep 10.1.1

    inet 10.1.1.2/24 brd 10.1.1.255 scope global noprefixroute eth1




tf_cnn_benchmarks를 이용한 GPU 성능 벤치마크 테스트



Deep learning용 GPU 서버의 성능 측정은 역시 deep learning에 가장 많이 사용되는 tensorflow를 이용한 benchmark test를 돌려보는 것입니다.  구체적으로 어떤 GPU에서는 몇 images/sec의 속도가 나와야 한다는 기준은 존재하지 않습니다.  테스트에 사용되는 neural network의 종류와 사소한 parameter, 그리고 어떤 dataset을 이용하느냐에 따라 그 성능은 천차만별이기 때문입니다.  또 테스트를 위해 labeling된 image dataset을 구하는 것도 쉽지 않습니다.


그런데 이런 어려운 문제를 극복하고 GPU를 이용한 tensorflow를 이용한 benchmark test를 수행하는 방법이 있습니다.  Tensorflow github에 공개된 tf_cnn_benchmarks를 이용하는 것입니다.  이 테스트는 더 이상 update되고 있지는 않지만 다음과 같은 장점이 있어서 아직도 널리 쓰이고 있습니다.


1) 사용방법이 간단

2) GPU 개수를 조절해가며 테스트 가능

3) CPU만으로도 테스트하여 CPU 대비 GPU 성능도 평가 가능

4) Test용 image dataset을 별도로 준비하지 않아도 python code에서 합성하여 사용

5) 성능 평가 수치를 images/sec로 간단명료하게 제시


이를 POWER9 processor를 장착한 IBM POWER 서버에서 수행하기 위해서는 먼저 다음과 같이 anaconda package를 download 받아 설치합니다.


[cecuser@p1226-kvm1 ~]$ wget https://repo.anaconda.com/archive/Anaconda3-2020.07-Linux-ppc64le.sh


[cecuser@p1226-kvm1 ~]$ chmod a+x Anaconda3-2020.07-Linux-ppc64le.sh


[cecuser@p1226-kvm1 ~]$ ./Anaconda3-2020.07-Linux-ppc64le.sh


Do you accept the license terms? [yes|no]

[no] >>> yes


[/home/cecuser/anaconda3] >>>


Do you wish the installer to initialize Anaconda3

by running conda init? [yes|no]

[no] >>> yes



Anaconda 설치가 끝난 뒤 profile을 수행하면 conda environment가 가동됩니다.


[cecuser@p1226-kvm1 ~]$ . ~/.bashrc


(base) [cecuser@p1226-kvm1 ~]$


이제 IBM OPEN-CE (구 명칭 IBM PowerAI 또는 Watson Machine Learning Community Edition), 즉 IBM ppc64le 환경에서 쉽게 deep leanring 관련 open source conda package를 설치할 수 있도록 해주는 conda channel을 등록합니다.


(base) [cecuser@p1226-kvm1 ~]$ conda config --prepend channels https://public.dhe.ibm.com/ibmdl/export/pub/software/server/ibm-ai/conda/


이 tf_cnn_benchmarks는 python 3.6 환경에서 수행하므로 다음과 같이 python 3.6용 conda virtual environment를 생성합니다.  여기서는 이름을 wmlce_env로 정했습니다.


(base) [cecuser@p1226-kvm1 ~]$ conda create --name wmlce_env python=3.6


방금 만든 wmlce_env 환경을 activate 합니다.  


(base) [cecuser@p1226-kvm1 ~]$ conda activate wmlce_env


이제 prompt 맨 앞부분이 (wmlce_env)로 바뀐 것을 보실 수 있습니다.  이제 OPEN-CE를 설치합니다.  구명칭인 PowerAI라는 이름의 패키지를 설치하시면 됩니다.  네트워크 환경에 따라 시간이 꽤 걸릴 수 있습니다.  (30분 ~ 몇 시간)


(wmlce_env) [cecuser@p1226-kvm1 ~]$ conda install powerai


그러고 난 뒤, 다음과 같이 tensorflow의 하위 github인 benchmarks를 clone 합니다.


(wmlce_env) [cecuser@p1226-kvm1 ~]$ git clone https://github.com/tensorflow/benchmarks


이제 그 중 tf_cnn_benchmarks로 들어갑니다.


(wmlce_env) [cecuser@p1226-kvm1 ~]$ cd benchmarks/scripts/tf_cnn_benchmarks


이 directory에 들어있는 tf_cnn_benchmarks.py를 수행하면 됩니다.  이때 다음과 같은 parameter를 주고 수행하면 됩니다.


먼저, GPU를 1개 이용한 테스트입니다.   아래 테스트는 NVIDIA P100 GPU를 이용한 것입니다만 공식적인 수치는 아니며 환경에 따라 또 다른 수치가 나올 수 있으니 참고용으로만 쓰십시요.


(wmlce_env) [cecuser@p1226-kvm1 tf_cnn_benchmarks]$ python tf_cnn_benchmarks.py --num_gpus=1 --batch_size=32 --model=resnet50 --variable_update=parameter_server --data_format=NHWC --num_batches=640


Done warm up

Step    Img/sec total_loss

1       images/sec: 224.9 +/- 0.0 (jitter = 0.0)        8.108

10      images/sec: 225.9 +/- 0.2 (jitter = 0.6)        8.122

20      images/sec: 226.0 +/- 0.2 (jitter = 0.4)        7.983

...

620     images/sec: 221.4 +/- 0.6 (jitter = 0.7)        7.772

630     images/sec: 221.4 +/- 0.6 (jitter = 0.7)        7.676

640     images/sec: 221.5 +/- 0.6 (jitter = 0.7)        7.779

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

total images/sec: 221.40



만약 GPU 2장을 쓰고 싶으시면 아래와 같이 --num_gpus=1 대신 --num_gpus=2를 쓰시면 됩니다.


(wmlce_env) [cecuser@p1226-kvm1 tf_cnn_benchmarks]$ python tf_cnn_benchmarks.py --num_gpus=2 --batch_size=32 --model=resnet50 --variable_update=parameter_server --data_format=NHWC --num_batches=640



GPU의 성능이 제대로 나오고 있는 것인지 보는 가장 직관적이고 좋은 방법은 이 동일한 테스트를 CPU로 돌려보는 것입니다.  아래와 같이 --device=CPU를 쓰시면 CPU로만 수행이 가능합니다.  역시 CPU 성능 및 개수와 밀접한 상관이 있으므로, 아래 수치는 참고로만 쓰십시요.



(wmlce_env) [cecuser@p1226-kvm1 tf_cnn_benchmarks]$ python tf_cnn_benchmarks.py --device=CPU --batch_size=32 --model=resnet50 --variable_update=parameter_server --data_format=NHWC --num_batches=640


Done warm up

Step    Img/sec total_loss

1       images/sec: 3.0 +/- 0.0 (jitter = 0.0)  8.108

10      images/sec: 3.0 +/- 0.0 (jitter = 0.0)  8.122

20      images/sec: 2.9 +/- 0.0 (jitter = 0.0)  7.983

...

620     images/sec: 2.9 +/- 0.0 (jitter = 0.0)  7.750

630     images/sec: 2.9 +/- 0.0 (jitter = 0.0)  7.667

640     images/sec: 2.9 +/- 0.0 (jitter = 0.0)  7.805

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

total images/sec: 2.91

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




참고로 위 GPU 테스트를 수행할 떄의 nvidia-smi tool을 보면 아래와 같이 GPU 사용률을 보여줍니다.  



Tue Oct 20 04:23:57 2020

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

| NVIDIA-SMI 440.33.01    Driver Version: 440.33.01    CUDA Version: 10.2     |

|-------------------------------+----------------------+----------------------+

| 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...  On   | 00000001:00:01.0 Off |                    0 |

| N/A   51C    P0   240W / 300W |  15677MiB / 16280MiB |     96%      Default |

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


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

| Processes:                                                       GPU Memory |

|  GPU       PID   Type   Process name                             Usage      |

|=============================================================================|

|    0     16243      C   python                                     15667MiB |

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