« 2020年1月 | トップページ | 2020年3月 »

2020年2月

2020年2月16日 (日)

Kerberosの旅 - 再出発

ちょっとづまづいて、最初からやりなおし。

KDCサーバー上の作業

まずはKDCをインストールするサーバーのFirewallを止める。
# systemctl disable firewalld
# service firewalld stop

# setenforce 0
# vi /etc/selinux/confog   SELENUX=disabledに設定

/etc/hostname
localhostをkdc.pathpilot.jp に変更。

/etc/hosts
kdc.pathpilot.jp, h-client-1.pathpilot.jp, node1.pathpilot.jp を登録。
node1はサーバー、h-client-1はクライアントに設定。クライアントからサーバーへのsshをKerberos認証化することがゴール。

Kerberosサーバーのインストール
# yum install krb5-server

/var/kerberos/krb5kdc/kdc.confの編集
[realms]
 PATHPILOT.JP = {
   ....
   supported_enctypes =  aes256.... aes128.... arcfour.... <- とりあえず左記の3種類のみ
}

# krb5_util create -r PATHPILOT.JP -s

/etc/krb5.confの編集
変更前:
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:per....
変更後:
default_realms = PATHPILOT.JP
# default_cchache_name = KEYRING:per....

Kerberosサービスの起動とOS起動時の自動起動設定
# systemctl start krb5kdc
# systemctl start kadmin
# service krb5kdc.service start
# service kadmin.service start

KDCクライアント上の作業

以下をh-client-1とnode1の両方に実施する

/etc/krb5.confの編集

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
default_realm = PATHPILOT.JP
#default_ccache_name = KEYRING:persistent:%{uid}

[realms]
PATHPILOT.JP = {
kdc = kdc.pathpilot.jp
admin_server = kdc.pathpilot.jp
}

[domain_realm]
.pathpilot.jp = PATHPILOT.JP
pathpilot.jp = PATHPILOT.JP

ーーーーーーーーーーーーーーーーーーーー
以上でKDCサーバーとKDCクラアンとの事前準備は完了した。
次に実際の認証確認を行う。

KDCクライアント上での作業

ユーザーとしてalphaを作成する。
# useradd alpha
# passwd alpha

KDCサーバー上での作業

principalとしてalpha/kdc.pathpilot.jpを登録する。
[root@h-client-1 ~]# kadmin.local
kadmin.local: addprinc alpha/kdc.pathpilot.jp
WARNING: no policy specified for alpha/kdc.pathpilot.jp@PATHPILOT.JP; defaulting to no policy
Enter password for principal "alpha/kdc.pathpilot.jp@PATHPILOT.JP":
Re-enter password for principal "alpha/kdc.pathpilot.jp@PATHPILOT.JP":
Principal "alpha/kdc.pathpilot.jp@PATHPILOT.JP" created.
kadmin.local:

KDCクライント上での作業

KDCサーバー上でalphaのprincipal登録ができたので、今度はKDCクライアントであるh-client-1からalphaの認証を行ってみる。
[root@h-client-1 ~]# su - alpha
最終ログイン: 2020/02/16 (日) 14:46:03 JST日時 pts/0
[alpha@h-client-1 ~]$ kinit alpha/kdc.pathpilot.jp
Password for alpha/kdc.pathpilot.jp@PATHPILOT.JP:
[alpha@h-client-1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: alpha/kdc.pathpilot.jp@PATHPILOT.JP

Valid starting               Expires                        Service principal
2020-02-16T14:59:19  2020-02-17T14:59:19  krbtgt/PATHPILOT.JP@PATHPILOT.JP
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
[alpha@h-client-1 ~]$
無事完了。
node1でも同様に確認。

ーーーーーーーーーーーーーーーーー
以上でh-client-1とnode1にてKerberos認証が使えるようになった。
次に、h-client-1からnode1のsshをKerberos認証で行う。

Kerberos認証によるsshを行うには、principalの鍵をKDCに発行してもらい、その鍵にてクライアントを認証することになる。
そこで、再びKDCサーバーに戻って、principal alphaの鍵を発行する。この鍵のことをKey Table、略してKeytabと呼ぶ。

KDCサーバー上の作業

Key Tableにprincipal alphaのKeyを追加する。追加と言ってもこれが初めてのKeyなるのだが、、、
kadmin.local: ktadd -k /etc/ssh-krb5.keytab alpha/kdc.pathpilot.jp
Entry for principal alpha/kdc.pathpilot.jp with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/ssh-krb5.keytab.
Entry for principal alpha/kdc.pathpilot.jp with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/ssh-krb5.keytab.
Entry for principal alpha/kdc.pathpilot.jp with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/ssh-krb5.keytab.
kadmin.local:
/var/kerberos/krb5kdc/kdc.confでsupported_enctypesをaes235, aes128, arcfourの3つを指定しているので、この3つに対応するKeyがKeytableに追加されて/etc/ssh-kerb5.keytabに保存される。 -kオプションを指定しないと、Defaultとして/etc/krb5.keytabに保存される。
このKeytabをh-client-1の/etcにscpを使ってコピーする。

KDCクライアント上の作業

KDCサーバーからscpされた/etc/ssh-krb5.keytabをユーザーalphaからアクセス出来るようにオーナー変更する。Root権限でないと変更できないので注意。
# chown alpha /etc/ssh-krb5.keytab
次にalphaユーザーにてkinitを実行する
[alpha@h-client-1 ~]$ kinit alpha/kdc.pathpilot.jp@PATHPILOT.JP -kt /etc/ssh-krb5.keytab

---- 今日はここまで。

 

2020年2月12日 (水)

Kerberosの旅

Kerberosをインストールしてみた。

参考にさせて頂いのは以下のリンク。
Kerberosのインストール手順

まずはドメイン名はとりあえず、自分が持っている以下として作業を進める。
pathpilot.jp

ホスト名は以下に設定。
sfuji.pathpilot.jp
/etc/hostnameをそのように変更した。
変更前:
localhost.localdomain
変更後:
sfuji.pathpilot.jp

以下を実行してKrberosをインストール
# yum install krb5-server krb5-workstation

まずはサーバー側の設定をおこなう。
以下のkdc.confファイルを修正する。
/var/kerberos/krb5kdc/kdc.conf
修正後
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88

[realms]
PATHPILOT.JP = {
   master_key_type = aes256-cts
   acl_file = /var/kerberos/krb5kdc/kadm5.acl
   dict_file = /usr/share/dict/words
   admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
   supported_enctypes = aes256-cts:normal aes128-cts:normal arcfour-hmac:normal
}

そして、realm名PATHPILOT.JPでKDCの初期化を実行。

# kdb5_util create -r PATHPILOT.JP -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'PATHPILOT.JP',
master key name 'K/M@PATHPILOT.JP'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
#

次にクライアント側の設定を行う。
krb5.confファイルを更新する。Realmの更新と、kdcとadmin_serverを更新する。
# vi /etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
default_realm = PATHPILOT.JP
#default_ccache_name = KEYRING:persistent:%{uid}

[realms]
PATHPILOT.JP = {
kdc = sfuji.pathpilot.jp
admin_server = sfuji.pathpilot.jp
 }

[domain_realm]
.pathpilot.jp = PATHPILOT.JP
pathpilot.jp = PATHPILOT.JP

default_ccache_nameは参考にさせて頂いたURLの情報によりコメントアウト。

ここになってちょっと心配になったので、/etc/hostsに自分自身を書き込んでおく。なにしろDNSがありませんから。。。。
192.168.1.87 sfuji.pathpilot.jp

次に、サーバー側の仕事としてKDCとkadminをスタートする。
# systemctl start krb5kdc
# systemctl start kadmin
無事スタートしたことを確認する。
# systemctl status krb5kdc
# systemctl status kadmin

次にプリンシパルを登録してみる。ここではユーザーalphaのプリンシパルを作ってみる。
# kadmin.local
Authenticating as principal root/admin@PATHPILOT.JP with password.
kadmin.local: listprincs
K/M@PATHPILOT.JP
kadmin/admin@PATHPILOT.JP
kadmin/changepw@PATHPILOT.JP
kadmin/sfuji.pathpilot.jp@PATHPILOT.JP
kiprop/sfuji.pathpilot.jp@PATHPILOT.JP
krbtgt/PATHPILOT.JP@PATHPILOT.JP
kadmin.local: addprinc alpha/sfuji.pathpilot.jp
WARNING: no policy specified for alpha/sfuji.pathpilot.jp@PATHPILOT.JP; defaulting to no policy
Enter password for principal "alpha/sfuji.pathpilot.jp@PATHPILOT.JP":
Re-enter password for principal "alpha/sfuji.pathpilot.jp@PATHPILOT.JP":
Principal "alpha/sfuji.pathpilot.jp@PATHPILOT.JP" created.
kadmin.local: quit
#

これでalphaのプリンシパルが登録された。

以下を実行してみる。
[root@localhost ~]# su - alpha  
[alpha@sfuji ~]$ kinit alpha/sfuji.pathpilot.jp@PATHPILOT.JP
Password for alpha/sfuji.pathpilot.jp@PATHPILOT.JP: 
[alpha@sfuji ~]$ 

[alpha@sfuji ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1002
Default principal: alpha/sfuji.pathpilot.jp@PATHPILOT.JP

Valid starting               Expires                       Service principal
2020-02-13T21:10:25 2020-02-14T21:10:25 krbtgt/PATHPILOT.JP@PATHPILOT.JP
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
[alpha@sfuji ~]$

このプリンシパルでチケット発行されがキャッシュされていることを確認。動いている。

次にクライアントからのアクセスを試す。
クライアントマシーンに以下をインストール。
yum install krb5-workstation

 

2020年2月11日 (火)

ゲストOSインストール済の仮想サーバーのOS再インストール

仮想サーバーを移動したら動かなくなった。理由は分からず。理由を調べることが目的ではないので、OSから再インストールを試みる。その場合の手順備忘録:

設定の編集からデータストアISOファイルを選択。ISOファイルデータストアへのアップロードは「ESXi6.0仮想マシーンへのisoイメージ...」参照。パワーオン時に接続をチェック。
Photo_20200211180401

オプションタブの起動オプションで「次回仮想マシンの起動時に、、、」にチェック。
Photo_20200211180501

これで起動するとBIOS画面が現れる。BootタブでCD-ROM Driveを最上位に持ってきて、F10で保存してExit。
Bios

ISOイメージから起動する。

次回起動時にもISOイメージから立ち上がってしまうから、パワーオン時に接続のチェックは外しておく。

AmbariでKerberos

KDCなどを持っていない自分はKerberosを活性化できないけれども、AmbariでKerberos設定する入り口をのぞいてみた。

AmbariのDashboardのメニュー下のほうにKerberosがある。
Kerberos1

これを選ぶと以下の警告が。。。
Kerberos2

以下の確認画面が出てくる。ここでExisiting MIT KDCのチェックボックスにすべてチェックをいれるとNEXTボタンがEnableになる。
Kerberos3

Kerberos環境パラメータの入力画面が現れる。ここに必要なパラメータを正しく設定出来る者のみが次のステージにすすめるようだ。
Kerberos4

未だ自分にはその資格がないのであった。

試しにHadoop Clientのインストール

Hadoop2.7.3をインストール

構成は以下:

hadoop client (h-client-1)
  |
 + hadoop namenode (h-namenode)
 + hadoop datanode (h-datanode-1)
 + hadoop datanode (h-datanode-2)

2.7.3 は以下からゲットした。
# wget https://archive.apache.org/dist/hadoop/core/hadoop-2.7.3/hadoop-2.7.3.tar.gz
# tar xf hadoop-2.7.3.tar.gz

~/.bashrcを変更

export JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk
export HADOOP_HOME=~/hadoop-2.7.3
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
export PATH=$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$JAVA_HOME/bin:$PATH

変更を反映させるには以下を実行

source ~/.bashrc

予め/etc/hostsにはhadoop構成ノードを登録しておく

「パスフレーズなしでssh構成」参照

# ssh-keygen -t rsa -P '' -f ~/.ssh/id-rsa
# sshpass -p "パスワード" ssh-copy-id -i ~/.ssh/id-rsa.pub -o "StrictHostKeyChecking no" h-datanode-1

h-datanode-2に対しても同様に。

core-site.xml, hdfs-site.xml, mapred-site.xml, yarn-site.xml をコピー。 scpにてetc/hadoop配下のファイルを全てコピーする。
# scp hadoop-2.7.3/etc/hadoop/* h-datanode-1:$HADOOP_HOME/etc/hadoop

マスターノード(namenode)で以下を実行・確認。

# hdfs dfs -mkdir -p .
# hdfs dfs -ls -R /user
drwxr-xr-x    - root supergourp     0    2020-02-10 18:40  /user/root

クライアントノードのインストール

クライアントノードにhadoop-2.7.3.tar.gzをインストールする。
h-namenodeからetc/hadoop配下のファイル(つまりxmlファイル)を総コピーする。
# scp $HADOOP_HOME/etc/hadoop/* 192.168.1.86:$HADOOP_HOME/etc/hadoop

この状態でクライアントから以下を実行すると…

hdfs dfs ls -R /user
ls: No Route to Host from ……: ホストへの経路がありません。…となり、namenodeに到達できない。

で、h-namenodeのFirewallを停止した。クライアント側のFirewallはそのままでも大丈夫だった。
# systemctl stop firewalld
# service firewalld stop <- 恒久化のため。

クライアントからアクセスできるようになった。

Ambariのインストール

だんだん深みにはまっていくHadoopの世界。Ambariはその深みから救ってくれるかもしれないとの期待のもと、本日インストール実施。

用意した仮想サーバーはAmbariインストール先の1台とHDP展開先サーバー3台(詳細べ後述)の計4台。

まずはAmbariのインストールパッケージの入手
Https://docs.cloudera.com/HDPDocuments/Ambari
ここで今回インストールするHadoopと同じバージョン2.7.3を選択。

上記URLのガイドに従ってInstallationの事前準備実施。
systemctl disable firewalld
service firewalld stop
昨夜、NoRouteToHostエラー発生でハマったところなので重要。
それ以外にも以下を確認。

[root@localhost ~]# timedatectl
Local time: 火 2020-02-11 07:19:10 JST
Universal time: 月 2020-02-10 22:19:10 UTC
RTC time: 月 2020-02-10 22:19:10
Time zone: Asia/Tokyo (JST, +0900)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a

[root@localhost ~]# setenforce 0
[root@localhost ~]# vi /etc/selinux/config <- SELINUX=disabledに設定
[root@localhost ~]# umask
0022

Ambari Repositoryをダウンロード

wget -nv http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.6.2.0/ambari.repo -O /etc/yum.repos.d/ambari.repo

yum install ambari-server

無事インストールが完了したらambariのセットアップ。
ambari-server setup

Ambari account: root

iptablesが動いていると以下の警告が出たら、yを選択する前に慌ててfirewalldを停止すること。停止方法は上記参照。
WARNING: iptables is running. Confirm the necessary Ambari ports are accessible. Refer to the Ambari documentation for more details on ports.
OK to continue [y/n] (y)? y

JDKはOracle JDKを選択

Cofiguring database…ではPostgreSQL (Embedded)を選択

以下はAmbari 2.6.2.0では表示されなかった。。。
Database admin user(postgres): postgres
Database name (ambari): ambari
Postgre schema (ambari): ambari
Username (ambari): ambari
Enter Database Password (bigdata): bigdata

全てのインストールが終わったら、ambari serverのスタート

ambari-server start

無事スタート。再確認。

ambari-server status

ウェブブラウザーにてサーバアドレス:8080で、user/passwd=admin/adminでログオン
20200211-80819

メニューがあまり無い。Cluster Managementを選択するとCreate a Clusterとなる。Ambariは自らを通してCreateしたClusterしか管理しないってことか。。。
とりあえず先にすすんでみる。Cluster名をambari01とした。

20200211-83519

選択できるHDPバージョンにはDefaultで3.xしかない。HDFSは2.7.3を入れたいのでAdd Versionを選ぶ。

20200211-84911

Version Definition Fileに関する情報は以下にあった。
https://docs.cloudera.com/HDPDocuments/Ambari-2.6.2.0/bk_ambari-installation/content/hdp_26_repositories.html
ここでHDP 2.6.5を選んでみた。というか、Googleってみたら2.6.5の次は3.xみたいな雰囲気だったので。。。
Version Definition FileのURLは以下。
http://public-repo-1.hortonworks.com/HDP/centos7/2.x/updates/2.6.5.0/HDP-2.6.5.0-292.xml
Add Versionを実行して展開してみたら、HDFSは2.7.3となっていた。ビンゴ。

20200211-85028

画面をスクロールアップするとNEXTボタンが出てくる。
20200211-85758

新たにClusterを作成する環境としてESXi上に、以下のようにCentOS7サーバーを新たに3台用意した。
192.168.1.76 a-master.pathpilot.jp
192.168.1.77 a-slave-1.pathpilot.jp
192.168.1.78 a-slave-2.pathpilot.jp
これらをAmbariをインストールしたCentOSサーバーの/etc/hostsに追記した。

次にssh private keyを生成。
# ssh-keygen -t rsa -P '' -f ~/.ssh/ud-rsa

20200211-95620

おっと、Failedとなった。
20200211-95738

赤いFailedをクリックして理由を確認。アクセス拒絶、パスワード指定していないから当然だ。
20200211-95923  
やっぱり予め鍵はターゲットサーバーに分配しておかねばならない、当たり前か。
そこで以下を実行。
sshpass -p "rootのパスワード” ssh-copy-id -i ~/.ssh/id-rsa.pub -o "StrictHostKeyChecking no" a-master.pathpilot.jp
同様の操作をa-slave-1, a-slave-2にも実行。

再挑戦。やっぱりFailed。でも様子が違う。
けっこう頑張って動いている。
20200211-102207

しかし、、、
20200211-102226

エラーメッセージの全文は以下のとおり。
Command start time 2020-02-11 10:17:48
Host registration aborted. Ambari Agent host cannot reach Ambari Server 'h-client-1:8080'.
Please check the network connectivity between the Ambari Agent host and the Ambari Server
Connection to a-master.pathpilot.jp closed.
SSH command execution finished
host=a-master.pathpilot.jp, exitcode=1
Command end time 2020-02-11 10:17:50
ERROR: Bootstrap of host a-master.pathpilot.jp fails because previous action finished with non-zero exit code (1)
ERROR MESSAGE: Connection to a-master.pathpilot.jp closed.
STDOUT: Host registration aborted. Ambari Agent host cannot reach Ambari Server 'h-client-1:8080'. 
Please check the network connectivity between the Ambari Agent host and the Ambari Server
Connection to a-master.pathpilot.jp closed.

Amabi Agentが各ターゲットノードで動くときにh-client-1が見えないといっているようだ。ちなみにh-client-1はAmbariをインストールしたHadoop Client。そこで、Ambariサーバーが持つ/etc/hostsをターゲットノードにばらまいた。このhostsファイルにはHadoop Clientから見えるホスト全てが登録されている。
# scp /etc/hosts a-master.pathpilot.jp:/etc/hosts  他のノードに対しても同様。

ターゲットの登録に成功。
Success
しかし、先に進もうとすると、「ちゃんと確認してね!」といったメッセージが出た。画面下あたりをみると、Click here to see the warningsとある。そこをクリックすると、、、
Hostcheck

ターゲットノードでFirewallが動いているぞ、と言っている。全部Disableにする。NextをクリックするとFile System選択画面になった。
Choosefilesystems 
初めて読む名前ばかり。とりえあずHDFSとYARN+MapReduce2のみにチェックをいれる。NextをクリックしたらZooKeeperが必要だから入れるとのメッセージ。OKをクリック。

Zookeeper

次にAmberi Metricsがはいってないが良いかときいてくるので、もどってチェックをいれる。
Ambarimetrics

Apache Rangerについても同様。
Apache Atlasについても同様。
Infra Solrについても同様。
HBaseについても同様。
KafkaはZooKeeper同様に必要だから自動で入れると通知。

ようやく先に進んだ。
Assignmaster1 Assignmaster2

選択した機能がばらまかれている。
Assign Slaves and Clientsに進むと以下の画面となった。Assignslaves
自動設定されたままで良いのか迷うが、ここでいろいろ考えてもしょうがないので、とりあえずこのままで先に進む。

Customize Servicesに入る。
Credentialではパスワードはいずれもpassw0rdに設定。
Credentials

DirectoryはDefaultのまま。
Directories

Accountsもそのまま。
Account1 Account2

で、All Configurationが表示された。
Allconfig
Advancedに赤マークが付いていて、先にすすめない。
Advanced
理由はhadoop proxyuserが未設定。とりあえずrootと設定。
Coresite

更に5つ。
Reqconfig

Atlas password: passw0rd
Ranger admin_password: passw0rd
Ranger DB host: 192.168.1.86 (Ambariをインストールしたサーバーを適当に設定)
Ranger password: passw0rd
Ranger DB Admin password: passw0rd
これでNextがクリックできるようになった。

やっとDeployできるとことにたどり着いた。

Review

DeployをクリックするとTaskが初期化されて、、、
Initialize

テストが始まる。
Installtest

とりあえず完了。Warningが出たようなのでProgress Barが黄色になっている。Complete  

RangerDB Hostアドレスを適当に設定したのが原因だと思う。
Warning

Starting services failedと記録されたが、一応は完了。
Finished

一通りおわってからDashboardにもどる。メニューには今インストールしたサービスがが並んでいる。いずれもサービスが開始されていないで赤く表示されている。
Hdfs1

HDFSをスタートしてみる。若干の時間はかかるものの無事スタートできた。
Hdfs2

ここまで約6時間かかった。

2020年2月 8日 (土)

Spectrum Scale導入作業

Spectrum ScaleをCentOS7に導入する。
CentOS 7.7
Spectrum Scale 5.0.4.2

準備作業

パッケージ導入
# yum -y install kernel-devel cpp gcc gcc-c++ binutils ksh m4

SELinuxの無効化
# getenforce で状態確認
Enforcing : 現在有効
Permissive:現在無効
# setenforce 0:無効化 
# setenforce 1:有効化
永続的に無効化
/etc/selinux/configを編集
SELINUX=disabled  <- 有効化の場合はenforcing
サーバー再起動

chronyの時刻同期
#timedatectl にてNTP Synchronizedとなっているか確認。Defaultで同期しているはず。
/etc/chrony.confにて適当なNTPサーバーが設定されているか確認。
#systemctl restart chronyd で再起動。

firewallの無効化
#firewall-cmd --state 
running <- 有効な場合、無効な場合は not running
#systemctl stop firewalld

ssh鍵交換の設定
「パスフレーズなしでssh構成」参照

/etc/hosts
クラスター・メンバーの登録

Spectrum Scaleの入手
FixCentralからSpectrum ScaleのData Management Editionをダウンロードする

ファイルの展開
ダウンロードしたxxx-installを実行する。/usr/lpp/mmfs以下に展開される。

パッケージの導入
以下ディレクトリに移動
# cd /usr/lpp/mmfs/5.0.4.2/gpfs_rpms
インストール実行
# rpm -ivh gpfs.adv* gpfs.base*.rpm gpfs.docs*.rpm gpfs.gpl*.rpm gpfs.gskit*.rpm gpfs.msg*.rpm gpfs.license*.rpm gpfs.compression*.rpm

ビルド
以下を実行
# /usr/lpp/mmfs/bin/mmbuildgpl
但し、素の状態では以下のエラーがでる。
Cannot find a valid kernel header file. One of these files should exist.
 /lib/modules/3.10.0-1062.el7.x86_64/build/include/linux/version.h
 /usr/src/linux-3.10.0-1062.el7.x86_64/include/linux/version.h
 /usr/src/kernels/3.10.0-1062.el7.x86_64/include/generated/uapi/linux/version.h
 /lib/modules/3.10.0-1062.el7.x86_64/build/include/generated/uapi/linux/version.h
CentOS 7.7ではversion.hは/usr/src/kernelsの下のディレクトリにある。途中のディレクトリ名が期待に合っていないので、そのディレクトリをコピーし、ディレクトリ名を期待に合うものに変更する。結果、以下となる。
[root@master ~]# ls -l /usr/src/kernels
合計 8
drwxr-xr-x. 22 root root 4096 2月 7 14:36 3.10.0-1062.12.1.el7.x86_64 <- 素のディレクトリ
drwxr-xr-x 22 root root 4096 2月 7 14:36 3.10.0-1062.el7.x86_64   <- コピーして作ったディレクトリ
この状態にしてからビルドを実行する。

以上でScaleのインストールは完了する。

2020年2月 4日 (火)

パスワードなしでssh構成

クラスター構成ではパスワード無しでマスターサーバーがスレーブサーバーと会話してもらわないといけない。

なんだか難しそうだけれども、便利なコマンドを使うと案外簡単だったので備忘録。

# ssh-keygen -t rsa
出力先を指定しないとDefaultの出力先~/.ssh/id-rsaを選択肢として聞かれるのでパラメータとして指定する必要なし。

# ssh-copy-id root@相手先サーバー
以上を、自分を含むssh先サーバー全てに対して実行する。
# ssh 相手先サーバー date  などでパスワード無でsshできることを確認する。

以上でクラスター内の任意のサーバーノード間でのsshが実行できるようになるのだ。

補足:
相手先サーバーを再インストールすると相手先のIDが変わり通信ができなくなる。これを解消するには、
/[ホームディレクトリ]/.ssh/known_hosts に記載されている相手先サーバー名の行を削除し、ssh-copy-idを実行すれば良い。

 

ーーーー 以下は古い書き込み ------

まずマスターサーバーで鍵の作成。
[root@master ~]# ssh-keygen -t rsa -P '' -f ~/.ssh/id-rsa
Generating public/private rsa key pair.
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id-rsa.
Your public key has been saved in /root/.ssh/id-rsa.pub.
The key fingerprint is:
この下に鍵が表示されて、その鍵が.ssh/id-rsa.pubに保存される。

で、次にこの鍵をパスフレーズ無しでsshを実行する相手のサーバーに保存する。
そこで登場するのが便利なコマンド二つ。

一つ目:sshpass
このコマンドはsshにパスワードを入力してくれる。
ssh -p "パスワード" ssh 
これでsshにパスワードを渡してsshを実行してくれる。インタラクティブな操作がなくなるので自動化が可能。
素のCentOS 7.7には含まれていないのでyum install sshpassを実行することになる。

二つ目:ssh-copy-id
ssh先のサーバーの.ssh/autherized_kyesに元サーバーの公開鍵をコピーしてくれる。パラメータとして元サーバーの公開鍵ファイルを指定するだけ。
実際の実行結果は以下の通り。masterの公開鍵をnode1にコピーしている。

[root@master ~]# sshpass -p "パスワード" ssh-copy-id -i ~/.ssh/id-rsa.pub -o "StrictHostKeyChecking no" node1
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id-rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine, with: "ssh -o 'StrictHostKeyChecking no' 'master'"
and check to make sure that only the key(s) you wanted were added.

以下がパスフレーズ無しのssh実行結果。
[root@master ~]# ssh node1 date
2020年 2月 4日 火曜日 18:29:02 JST

よく使われる cat >> での追記の代わりになる(catコマンドパラメータ指定省略可能)。

便利かも。

 

 

 

 

ESXi6.0 仮想マシーンへのisoイメージからのゲストOSインストール

一度通ってきているはずなのに一時間ほど手間取ったので備忘録。

ESXiのWeb Console(VMware ESXi画面)
左側メニューからストレージ -> datastore1を選択し、右側のdatastore1画面のメニューからデータストアブラウザを選択。

01

データストアブラウザにてアップロードを選択。
 02
ローカル(ESXiホスト)のファイルシステムからisoイメージファイルを選択して、アップロード。

ちょっと時間がかかるけれどもisoイメージがdatastore1にアップロードが完了する。
03

vSphere Clientの仮想マシーンの設定の編集にて、CD/DVDドライバー1のデバイスのステータスでパワーオン時に接続にチェック、データストアISOファイルを選択してdatastore1にアップロードしたISOファイルを選択。
04

これで準備完了。仮想マシーンをパワーオンすれば、ISOイメージが立ち上がってゲストOSのインストールが始まる。

2020年2月 2日 (日)

hadoop namenodeへのアクセス

新しいマシーンにhadoopをインストールして、既設のNameNodeにアクセスしてみた。

既設Hadoop:疑似拡散モードで動いている192.168.245.155 (pnode)
新設Hadoop:192.168.245.156 (snode-0)

新設Hadoopのcore-site.xmlに以下を記述:

 <property>
    <name>fs.defaultFS</mame>
      <value>hdfs://192.168.245.155:9000</value>
 </property>

hdfs-site.xmlにreplicationを1でセット。

既に上記2台のマシーンはpassword-less sshできるように設定済み。

# sbin/start-dfs.sh
Starting namenodes on [pnode]    
pnode: starting namenode, logging to /root/hadoop-2.10.0/logs/hadoop-root-namenode-pnode.log
localhost: starting datanode, logging to /root/hadoop-2.10.0/logs/hadoop-root-datanode-snode-0.log
Starting secondary namenode [0.0.0.0]
0.0.0.0: starting secondarynamenode, loggoing to /root/hadoop-2.10.0/logs/hadoop-root-secondarynamenode-snode-0.out

これを見る限りnamenodeはpnodeをアクセスしようとしている。

hadoop-root-datanode-snode-0.logを見てみる.
Retrying connect to server: pnode/192.168.245.155:9000 が連発している。どうやらpnodeにつながっていないようだ。

#bin/hdfs dfs -ls -R を実行してみるが、やはりつながっていない。
ls: Call From snode-0/192.168.245.156 to pnode:9000 failed on connection exception: java.net.ConnectionExceptiopn:
接続を拒否されました; For mode details see:  http://wiki.apache.org/hadoop/ConnectionRefused 

#jps
10225 Jps
3298 DataNode
3527 SecondaryNameNode

NameNodeはローカルではなくpnodeだから、jpsには出てこない(のだろうと思う)。

pnodeで以下を実行
# nmap 192.168.245.155

PORT      STATE   SERVICE
22/tcp     open     ssh
....
8085/tcp  open     unknown
9000がない。
# nmap localhost

PORT      STATE   SERVICE
9000/tcp  open    cslistener

cslistenerが何なのか分からないけれども、とりあえず9000は開いている。

なんだか結局わからなくて、ここで中断。

« 2020年1月 | トップページ | 2020年3月 »