はじめに
メインフレーム(z/OS)の開発環境をエミュレートする製品としてZD&T(IBM Z Development and Test Environment)というものがあります。これは、言ってみればIntel/Linux上で稼働する疑似IBM Z環境という位置づけのものです。
ZD&Tにはいくつかエディションがありますが、ZD&T Enterprise Edition(ZD&T EE)はクラウド環境で稼働させることができるので、実際にIBM Cloudの仮想サーバー(IaaS)を使ってZD&Tを動かすということをやってみたいと思います。当記事および関連する一連の記事は、RHEL V7.7 および ZD&T V12.0.5を使用しています。
※IBM Cloud上の仮想サーバーやZD&Tは有償です。
まずは、そのベースとなる仮想サーバーの作成のところまでをやってみます。
関連記事
クラウド上でのメインフレーム開発環境構築 - (1) 仮想サーバー作成
クラウド上でのメインフレーム開発環境構築 - (2) ZD&T管理サーバーのインストール
クラウド上でのメインフレーム開発環境構築 - (3) ライセンス管理
クラウド上でのメインフレーム開発環境構築 - (4) ZD&Tインスタンス作成概要(ADCD)
クラウド上でのメインフレーム開発環境構築 - (5) ZD&Tインスタンス作成詳説(ADCD)
クラウド上でのメインフレーム開発環境構築 - (6) DeviceMapファイル補足
クラウド上でのメインフレーム開発環境構築 - (7) ネットワーク構成補足
クラウド上でのメインフレーム開発環境構築 - (8) ADCD IPL, Shutdown補足
クラウド上でのメインフレーム開発環境構築 - (9) DASD管理補足
クラウド上でのメインフレーム開発環境構築 - (10)既存ZD&Tからイメージ作成
ZD&T EE概要
ZD&Tは疑似IBM Z環境をIntel Linux上で動かすことができます。しかも単にz/OSが上がるだけではなく基本的な構成が行われた各種ミドルウェア(CICS, Db2, IMSなど)も含めた環境が提供されます。
Personal Editionだとライセンスをアクティベートするために物理的にUSBポートに特殊なデバイス(見た目はUSBメモリみたいなやつ)を指す必要がありますが、Enterprise Editionはクラウド環境での稼働を想定してS/Wベースのライセンスを使って(物理的なデバイス無しで)利用することができます。
全体像として以下のようなイメージになります。
- ZD&Tインスタンス(ZD&Tエミュレーター): IBM Zをエミュレートするもの。ZD&Tの本体。Knowledge Center上では"ZD&Tエミュレーター"という言い方してますが個人的には用語としてピンとこなかったのでここでは"ZD&Tインスタンス"という言い方にしています。
- ライセンス・サーバー: 各ZD&Tインスタンスのライセンスを管理するサーバー。
- Webサーバー: ZD&Tインスタンスをプロビジョニングするためのアプリケーションを稼働させるためのサーバー。(実体はLibertyなので本当は"Webアプリケーション・サーバー"としたいところですがまぁいいでしょう。)
- イメージ・ストレージ・サーバー: ZD&Tインスタンスを作成する際の元になるDASDイメージを管理するためのサーバー(≒FTPサーバー)
Enterprise Editionの場合ZD&Tインスタンスは専用の管理画面(Webサーバーで動くアプリ)からプロビジョニングの操作を行うことで構築できるようになっています。(ZD&T EE V12.0.3以降ではPersonal Editionと同様にWebサーバー無しでもZD&Tインスタンスを手動でインストール仕組みも提供されています。)
管理用サーバーであるライセンス・サーバー、Webサーバー、イメージ・ストレージ・サーバーは上のように3つの区画に分けて配置することもできますが、同一区画に構成することも可能です。(ZD&T EEではライセンス・サーバーとZD&Tインスタンスを同一マシン上に構成することはできません。)
今回は、Linuxの環境としては、管理用のサーバーx1(ライセンス・サーバー 兼 Webサーバー 兼 イメージ・ストレージ・サーバー)、ZD&Tインスタンス用のサーバーx1 を用意して環境を作成してみます。つまり今回構成するイメージはこんな感じを想定します。
ZD&Tインスタンス1つだとWebサーバーを介さずに個別に作った方が早そうですが、インスタンスを複製していく場合の操作イメージを確認するためにあえてWebサーバー、イメージストレージ・サーバーを用意してそこからZD&Tインスタンスを作成する手順を確認してみる予定です。
当記事ではガラとなるLinux環境整備のところまでを取り上げます。
※ちなみにZD&Tインスタンス用の仮想サーバーですが、OpenStack環境があればそこから仮想サーバーを払い出してZD&Tインスタンスを構成する、というやり方もできるようです。今回はOpenStack環境を準備する所まで手が回らないので個別にLinux環境を準備しています。
環境情報
IBM Cloud上にIaaSとしてのLinuxを作成する場合、現状では以下の2種類のサービスがあります。
- Virtual Server for Classic
- Virtual Server for VPC
Virtual Server for VPCの方が新しいのですが、Virtual Server for Classicだと管理用にSSL-VPNが使えるということでお手軽にアクセスできそうだったので今回はClassicの方を使うことにします(Virtual Server for VPCだとSSL-VPN接続不可のようです)。
今回はIaaS上にZD&Tを構築する部分にフォーカスしたく、仮想サーバーそのものの部分では余計な考慮を減らすためにそちらを選択しています。実際に環境構築する際はアクセス方法をどうするかを含めて検討が必要です。
※注意
参考: IBM Z Development and Test Environment 12.0.5 - Overview
ZD&T Enterprise Edition and Parallel Sysplex can work on cloud and VMs. You need to make sure that the underlying hardware is not changed by your cloud service provider. CPU or hard drive needs to be a static entity to ensure that all ZD&T editions work.
Cloud環境というのは物理的なH/Wや場所を意識しなくてよいというのが特徴の一つではありますが、ZD&Tは上の記述にあるようにH/Wに紐づいてライセンスの管理がなされます。書き方が曖昧ですが恐らくこの制約はライセンス・サーバーが稼働する仮想サーバーについての制約と考えられます。Cloud環境であってもライセンス・サーバーを稼働させる仮想サーバーについては特定のH/W上で稼働するようなメニューを選択する必要がありますのでご注意ください。(今回は一時的なテスト用に環境作っているだけなのでそこは考慮していません。)
その他使用するS/Wバージョンは以下の通り
RHEL V7.x
ZD&T EE V12.0.5
仮想サーバー構成
ここでは、まずZD&Tを構成するベースとなるLinux環境を2つIBM Cloud上に作っていきます。
仮想サーバーインスタンス作成
IBM Cloudのカタログから Virtual Server for Classicを選択
作成したい仮想サーバーの仕様に合わせて各種パラメータを設定し、最後に"作成"ボタンをクリック
RHEL V7.xを東京リージョンに作成、プロファイルとしては 4vCPU, Memory32GBで、500GBのディスクを追加しています。(2環境とも同じなので、このセットを2つ作成します)
直後は以下のような画面になります。
しばらくして画面を更新すると、IPアドレスがアサインされます。デバイス名の左側に時計マークが出ているのでまだプロビジョニング中です。
先頭の時計マークが消えたのでプロビジョニング完了したようです。5分くらいでしょうか。
これでサーバー2つ作成されて起動した状態となります。
これ以降、各サーバーの基本的な設定を行いますが、それぞれのサーバーに対して同じ操作を行います。
アクセス確認
取り急ぎSSHで接続確認してみます。
IBM Cloud画面の右上の管理 - アクセス(IAM)を選択し、左側のメニューからユーザーを選択、その後自分のユーザーを選択します。ユーザーの詳細タブで、VPN接続用パスワード設定を行います。
デバイスタブで対象の仮想サーバーへのアクセスが有効になっていることを確認します。
「SSL VPNアクセスを有効にする」にチェックを入れて保存
以下のガイドに従って、PCからSSL-VPN接続します。
VPNクライアントを導入して、作成したサーバーに近いVPNエンドポイント(今回の場合東京)に対して上のVPNユーザーで接続します。
参考: スタンドアロン VPN クライアント (Windows、Linux、および Mac OS X)
参考: 使用可能な VPN エンドポイント
VPN接続ができたら、次にOSのrootユーザーのパスワード確認します。
デバイスから当該仮想サーバーを選択し、左側のメニューからパスワードを選択します。そこにrootのパスワードが指定されていますので確認します(目のようなマークをクリックするとパスワードが表示されます)。
VPN接続した状態で、teratermなどからプライベートIPに対してSSHで上のrootユーザー/パスワードで接続できることを確認します。
ホスト名解決
両マシンはお互いにホスト名(zdt01, zdt02)でプライベート・ネットワーク経由でアクセスできるように、プライベートのIPアドレスとの紐づけを/etc/hostsにしておきます。
セキュリティ考慮
とりあえず作成された素の状態のLinuxにアクセスできるところまで確認できましたが、安全のため、SSH接続の際のroot無効化やパスワード認証無効化などを実施しておきます。
パブリックのIPアドレス
パブリックのIPアドレスについては、通信を限定するためにセキュリティグループを設定しておきます。
IBM Cloudの管理コンソールで、ClassicInfrastructure - Security - Network Security - Security Groupsを選択
Create Groupをクリック
名前を指定してCreate
作成したSecurty Groupをクリック
Inbound, Outboundについてのルールを適宜指定
仮想サーバーの管理画面で、パブリックのインターフェースに上で作成したセキュリティグループを設定。(要再起動)
念のため、一旦外部から直接アクセス可能なIPアドレスは無効化しておきます。
もしくは
sudo ip link set eth1 down
一通りセキュリティ周りの対応が済んだ後、必要になったら元に戻します。
管理用ユーザー作成/sudo設定
rootは直接使わないようにしたいので別の管理用ユーザーを作成し、sudo実行できるようにします。
まずユーザーを作成してパスワードを設定します。
[root@zdt01 ~]# useradd taguchi
[root@zdt01 ~]# passwd taguchi
Changing password for user taguchi.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
visudoで以下を編集します。
## Allows people in group wheel to run all commands
#%wheel ALL=(ALL) ALL
## Same thing without a password
%wheel ALL=(ALL) NOPASSWD: ALL
デフォルトだと上の設定が有効になっているので、上をコメントアウトして下のコメントアウトをはずします。
これによって、wheelグループはパスワード無しでsudoコマンド実行できるようになります。
上で作ったユーザーにwheelグループを付与します。
[root@zdt01 ~]# usermod -aG wheel taguchi
[root@zdt01 ~]# id taguchi
uid=1000(taguchi) gid=1000(taguchi) groups=1000(taguchi),10(wheel)
これで新たな管理用ユーザーでsudoできるようになりました。
(sudo vi /etc/ssh/sshd_configが実行できればOK)
公開鍵認証設定
SSHクライアント側(今回は自PCのWindows10)でキーペア作ります。
参考 マルチ・プラットフォームを扱うインフラ屋さんのための連携技術: SSH編
上の参考文書の通りキーペアを作って公開鍵をLinuxの/home/taguchi/.ssh/以下に転送します。同ディレクトリにauthorized_keysファイルを作成して公開鍵の内容をAppendします。
こんな感じになっていればOK。(パーミッションは要注意！)
[taguchi@zdt01 .ssh]$ pwd
/home/taguchi/.ssh
[taguchi@zdt01 .ssh]$ ls -la
total 16
drwxr-xr-x. 2 taguchi taguchi 4096 Sep 11 04:53 .
drwx------. 3 taguchi taguchi 4096 Sep 11 04:51 ..
-rw-r--r--. 1 taguchi taguchi 406 Sep 11 04:53 authorized_keys
-rw-r--r--. 1 taguchi taguchi 406 Sep 11 04:52 id_rsa.pub
Linux側のSSHサーバー設定(/etc/ssh/sshd_config)はデフォルトのままでOKだったので、これで接続確認をすればOKです。
sshコマンド、teratermでも、秘密鍵使ってtaguchiユーザーで接続できました。
SSHD設定変更
rootユーザー以外で公開鍵認証でのssh接続&sudo実行ができたので、SSHDの設定を変更してroot無効化、パスワード認証無効化を行います。ついでに念のためポート番号も変えておきます。
...
Port 2222
PermitRootLogin no
PasswordAuthentication no
...
これで、sudo systemctl restart sshd でSSH再起動します。
※既存のSSHセッションはsshd再起動しても生きているようなので、元のセッションは残したまま新たに接続できるか確認して、ダメだったら元のセッションで設定見直しましょう。ssh起動できなくなったら終わるので...
firewalld設定
※これは管理用サーバーを稼働させるLinux(zdt01)のみに設定します。
デフォルトではfirewallのサービスは無効化されているようですので、これを有効化します。firewallのデフォルト設定ではsshのデフォルトポートは通すようになっていますが、上でポート番号を変更しているので、新しく設定したポートを有効化するよう設定変更します。sudo vi /etc/firewalld/zones/public.xmlでpublic zoneの設定をします。
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="dhcpv6-client"/>
<port protocol="tcp" port="2222"/>
</zone>
上のように2222ポートをpublic zoneに追加します。
これで、sudo systemctl start firewalld.service コマンドを実行してfirewalldを起動します。
※この時、ポート番号を間違ったりすると、現行接続済のセッションも利用できなくなってSSHで繋がらなくなるので注意が必要です。firewalldの自動起動はdisabled状態で稼働確認しましょう。最悪繋がらななくなったらIBM CloudのコンソールからVirtual Serverをリブートすればfirewalldは停止状態で起動するので設定を修正できます。
OKだったら、sudo systemctl enable firewalld.service で自動起動を有効化しておきます。
脆弱性スキャン
ポータブル・ストレージ(SAN)のマウント
参考: IBM Cloud の 仮想サーバーに 追加ストレージ（ポータルブル・ストレージ）をマウントする
仮想サーバーを作成する際、追加で500GBのストレージをオプションで追加していますが、自動ではマウントされないのでマウントします。
まずは状況確認から。
[taguchi@zdt01 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 25G 0 disk
tqxvda1 202:1 0 1G 0 part /boot
mqxvda2 202:2 0 24G 0 part /
xvdb 202:16 0 2G 0 disk
mqxvdb1 202:17 0 2G 0 part [SWAP]
xvdc 202:32 0 500G 0 disk
[taguchi@zdt01 ~]$ df -Tm
Filesystem Type 1M-blocks Used Available Use% Mounted on
devtmpfs devtmpfs 15993 0 15993 0% /dev
tmpfs tmpfs 16004 0 16004 0% /dev/shm
tmpfs tmpfs 16004 9 15995 1% /run
tmpfs tmpfs 16004 0 16004 0% /sys/fs/cgroup
/dev/xvda2 ext3 24062 3365 19468 15% /
/dev/xvda1 ext3 976 129 797 14% /boot
tmpfs tmpfs 3201 0 3201 0% /run/user/1000
tmpfs tmpfs 3201 0 3201 0% /run/user/0
xvdcというブロックデバイスがありますのでこのデバイスをext4でフォーマットします。
[taguchi@zdt01 ~]$ sudo mkfs.ext4 /dev/xvdc
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
32768000 inodes, 131072000 blocks
6553600 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2279604224
4000 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
確認
[taguchi@zdt01 ~]$ sudo parted -l
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 26.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 1075MB 1074MB primary ext3 boot
2 1075MB 26.8GB 25.8GB primary ext3
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdb: 2147MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 32.3kB 2147MB 2147MB primary linux-swap(v1)
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvdc: 537GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 537GB 537GB ext4
マウントします。
[taguchi@zdt01 ~]$ sudo mount -t ext4 /dev/xvdc /mnt
[taguchi@zdt01 ~]$ df -Tm
Filesystem Type 1M-blocks Used Available Use% Mounted on
devtmpfs devtmpfs 15993 0 15993 0% /dev
tmpfs tmpfs 16004 0 16004 0% /dev/shm
tmpfs tmpfs 16004 9 15995 1% /run
tmpfs tmpfs 16004 0 16004 0% /sys/fs/cgroup
/dev/xvda2 ext3 24062 3366 19468 15% /
/dev/xvda1 ext3 976 129 797 14% /boot
tmpfs tmpfs 3201 0 3201 0% /run/user/1000
tmpfs tmpfs 3201 0 3201 0% /run/user/0
/dev/xvdc ext4 503837 73 478149 1% /mnt
マウントされました。
リブート後も自動マウントされるように、/etc/fstabを編集します。(最終行を追加)
#
# /etc/fstab
# Created by anaconda on Thu Oct 3 14:41:18 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=b894c135-27a1-4f7c-8cb1-8b3a69a05491 / ext3 defaults,noatime 1 1
UUID=1205ee90-24ba-4bed-af8d-7f9bf36008ed /boot ext3 defaults,noatime 1 2
LABEL=SWAP-xvdb1 swap swap defaults 0 0
/dev/xvdc /mnt ext4 defaults 0 0
入れておいた方がそうなパッケージのインストール
[taguchi@zdt01 ~]$ sudo yum install zip
[taguchi@zdt01 ~]$ sudo yum install unzip
[taguchi@zdt01 ~]$ sudo yum install net-tools
[taguchi@zdt01 ~]$ sudo yum install bind-utils
[taguchi@zdt01 ~]$ sudo yum install ftp
[taguchi@zdt01 ~]$ sudo yum install lsof
[taguchi@zdt01 ~]$ sudo yum install tree
([taguchi@zdt01 ~]$ sudo yum install lvm2)
ICOS(IBM Cloud Object Storage)利用の設定
ZD&Tを導入する場合、インストーラーにはz/OSや各種ミドルウェアが含まれるDASDイメージファイルなども含まれるため、サイズが非常に大きくなります(取捨選択はできるので全部は必要ないですが圧縮されたDASDイメージファイルで30～50GBくらい必要になります)。
ファイル転送用に、ICOSの設定をしておくとよいです。詳細は以下の記事参照。
参考: IBM Cloud Object Storageを介したファイル転送
ネットワークまわりの確認
こんな感じ
[taguchi@zdt01 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 06:99:5b:99:45:3f brd ff:ff:ff:ff:ff:ff
inet 10.xxx.xxx.xx2/26 brd 10.132.233.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fexx::xxxx:xxxx:xxxx:xx3f/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 06:4a:4b:68:34:bb brd ff:ff:ff:ff:ff:ff
inet 1xx.xxx.xxx.xx6/28 brd 1xx.xxx.xxx.127 scope global eth1
valid_lft forever preferred_lft forever
inet6 fexx::xxxx:xxxx:xxxx:xxbb/64 scope link
valid_lft forever preferred_lft forever
[taguchi@zdt01 ~]$ ip route
default via 161.202.139.113 dev eth1
10.0.0.0/8 via 10.132.233.193 dev eth0
10.132.233.192/26 dev eth0 proto kernel scope link src 10.132.233.242
1xx.xxx.0.0/16 via 10.132.233.193 dev eth0
1xx.xxx.xxx.xx2/28 dev eth1 proto kernel scope link src 1xx.xxx.xxx.xx6
166.8.0.0/14 via 10.132.233.193 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
[taguchi@zdt01 ~]$ cat /etc/resolv.conf
nameserver 10.0.80.11
nameserver 10.0.80.12
options single-request-reopen
まとめ
まずはIBM Cloud上にZD&Tを構成するための箱2つが準備できました。
