上でのansibleの導入と活用事例 · ansibleの要素 ansible inventory playbook ansible.cfg 対象への操作を記述対象を記述 ansible自体の設定ファイル

Copyright © 2019 EXA CORPORATION

Ｅｘａ

Ｖａｌｕｅ

Ｆｏｒｕ m

2019

zLinux上でのansibleの導入と活用事例

ビジネス基盤技術部基盤サービス第1室田中宏明

オープン基盤技術部第1開発室横山民史

1Copyright © 2019 EXA CORPORATION

もくじ• 本日お話すること、案件概要

• 前提知識

– z/Linux , ansibleのご紹介

• z/Linuxとansibleを使ったシステム構成

• 同構成の他システム導入事例

• 苦労したこと

• それでもスゴイz/Linux＋ansible

• z/Linux＋ansible今後の展望

※本資料に記載されているロゴ、システム名称、企業名称、製品名称は各社の登録商標または商標です。


本日お話すること、案件概要


本日お話すること

• IBM Z ※ 上で動く Linux サーバーにおける構成管理ツールを使ったシステム構築事例紹介

• 構築中で苦労したこと、良い点の紹介

※ 2017年7月 IBM社メインフレームコンピューターブランド名称を「IBM Z」に変更


案件概要

• お客様：官公庁関連お客様

• 利用者規模：全国3940万人(平成31年3月末)• 案件内容：基幹システム更改

• 期間：2018年8月～2020年1月


おおまかなスケジュール2018年

8月 2019年2020年

1月

要件確認基本設計

8～9月末移行設計詳細設計

10～11月末

保守テスト環境構築東本番

環境構築

2月中旬

西本番環境構築

3月末

アプリ構築システムテスト

各環境ミドルウェア構築

12～1月中旬

1月中旬～

2月中旬 2月中旬～

3月末

6月～11月末

1月中旬～

8月末

移行

12月サービスイ

ン


前提知識z/Linuxとは

ansibleとは


z/Liunxとは①

• IBM Z (メインフレーム )上で稼働するLinux

– IBM Z の論理区画(LPAR)上に直接導入したり

Hypervisor(z/VMまたはKVM)上の仮想計算機 (仮想マシン)に導入することが出来る

• アーキテクチャ

– s390(z/OSの前身)を継承する

z/Architectureで動作する。 (物理空間と仮想空間を 64ビットで管理)

– 各distributorから提供されている Linuxはs390(31bit版)および、s390x(64bit版)


z/Liunxとは②

• 利用可能なLinuxディストリビューション


z/Liunxと通常のLinuxの違い①

• 通常のLinuxと違うところ– 実はあまり変わらない

• 通常のLinuxと比べてz/Linuxのソース改修箇所は全体の数％程度

– Linuxのコード構造自体には変更なし• 改修箇所

– カーネル内のハードウェア依存コード

– デバイスドライバ

– アセンブラコード

– ざっくり言うと、『デバイス周り』しか変わらない


• ｚLinuxのデバイス

– ディスク

• FB形式：

– 通常の Linuxが使用するディスクと使われ方も見え方も同じ

– SCSIディスクとして/dev/sdxといった名称で認識される

– 複数経路にソフトウェア的にI/Oの最適化を図る

– 単独のI/Oのパフォーマンスが速い

• CKD形式：

– z/Linux独自の形式

– z/Linux独自のドライバが使用され、/dev/dasdxといった名称で認識される

– IBM Z のH/W機能であるChannel subsystemを使用してI/Oを行う

– 通常IBM Z におけるディスク接続は冗長性を考慮し、複数経路を用意する必要がある

– Channel subsystemが専用H/WとしてI/Oの最適化を担う

– 細かいI/Oが重なるようなケースでは最適化のオーバーヘッドが大きくなるため、CKD形式が

速い

z/Liunxと通常のLinuxの違い②


• ｚLinuxのデバイス

– ネットワークデバイス

• 通常のLinuxではひとつのポートに対してethxといったようにデバイスが割り

当てられる

• z/Linuxでは、IBM Z がQDIOというプロトコルを用いてポートを使用し、論理

的に複数デバイス(Read,Write,Data)として分割し、これらをグルーピングす

ることによってひとつのネットワークデバイスqeth-xxxxとして認識

z/Liunxと通常のLinuxの違い③


ansibleとは

• 構成管理ツールのひとつ– 他の構成管理ツールとしては、Puppet、chefなど

• 構成管理とは？– システムの設定、変更点、状態を管理すること– 構成管理ツールは構成をコードとして保管することを可

能にする（Infrastructure as Code）


従来のシステム構築と構成管理ツールを用いた構築

設計書

手順書

＋

設計書

手順書

手作業

コード実行

構成をコードとして保管

作業ミス・漏れ、煩雑な管理

作業ミス・漏れの減少、容易な管理繰り返し実行可能

ansible

inventory

playbook

ansible.cfg


ansibleの要素ansible

inventory

playbook

ansible.cfg

対象への操作を記述

対象を記述

ansible自体の設定ファイル

[web-server]server1server2name : deploy web serverhost : web-servertask : - group - user - zypper - copy

web-server.yml

role単位に分割し肥大化を解消

task単位に分割し管理が容易に

対象ごとの設定差異にも対応

confファイルの管理もより容易に


z/Linuxとansibleを使ったシステム構成


構築環境

• 今回導入したz/Linuxサーバー

– SLES 12 SP3 for IBM Z on zVM

• IBM Z 環境

– メインフレーム：zEC12– ハイパーバイザ：zVM 6.4

• z/Lnuxディストリビューション

– SUSE Linux Enterprise Server 12 SP3 for IBM Z

• 構築台数：179台

– 東本番環境53台、西本番環境 (災対環境)56台、保守環境56台、テスト環境14台


現行環境

基幹系システム[ホスト系 Db2z(統合DB)]

業務・運用・情報系システム[オープン系 z/Linux]

新規環境

業務・運用・情報系システム[オープン系 z/Linux]

本番

環境

保守

環境

システム構成(西側)

Storage [ DS8870 ]

SAN switch [ SAN384B-2 ]

Mainflame [zEC12 ]

HBA

FICON

LUN[FB]

LUN[FB]

・・・LUN[FB]

LUN[CKD]

LUN[CKD]

・・・LUN[CKD]

HBA

FICON

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

LPAR

z/OS

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( SLES12 )

zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( SLES12 )

zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( SLES12 )zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( SLES12 )

zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( S

LES

11 )

zVM 6.2

z/Linux OS

( S

LES

11 )

z/Linux OS

( S

LES

11 )z/Linux O

S

( SLE

S11 )

LPAR

z/Linux OS

( SLES12 )

zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( SLES12 )

zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( SLES12 )

zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( SLES12 )

zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

z/Linux OS

( SLES12 )zVM 6.4

z/Linux OS

( SLES12 )

z/Linux OS

( SLES12 )z/Linux O

S ( SLES12 )

LPAR

LPAR(≒z/VM)1区画あたり

4～16コア,4～80GBメモリ

の z/Linux 10台程度稼働

LPAR(≒z/VM)　 9区画z/Linux　　　　　 133台 vCPU　　　　　　348コア　メモリ　　　　　1248GB

LPAR　 16区画z/OS　 16台CP　 6コアメモリ　 316GB

[PU(処理装置 )] 6 CP , 35 IFL [MEM] 2071.5GB

LPAR(≒z/VM) 　 9区画z/Linux　　　　127台 vCPU　　　　　326コアメモリ　　　　1248GB　※オーバーコミット有

メインフレーム(IBM Z)1台にz/OS 16台(6コア,316GB)、z/Linux 260台(674コア,2496GB)が動作することに。


構成環境

• 構築台数多いし、構築期間も短い。。。

• よし。構成管理ツールで楽々構築だ！– 代表的な構成管理ツール

• Puppet• Chef• ansible


Puppet Chef Ansible

仕様言語 Ruby Ruby Python

開発年度 2005 2009 2012

アーキテクチャ Pull型 Pull型 Push型

エージェント有無有有無

実装

コード管理名称 manifest recipe playbook

コード記述言語独自言語 Ruby YAML

処理実行順序コンパイル時に決定

※記述通りにならないおよそ記述通り記述通り

構成管理ツールの比較検討


ansibleがいい点

• 可読性の高いフォーマット（ＹＡＭＬ)– pythonをベースに構造、オブジェクトを文字列として直列的に表

記すること

• エージェントレスであるため、導入が容易– ansible自体はansibleを実行するサーバーへのみ導入

• 記述通りの処理– 意図しない動作を抑止

• 冪等性が担保– 事前に対象の状態を確認し、操作の要否を決定

name : add useruser - name:taro - UID:1000 - home:/home/taro


OS User[ansible]

OS User[ansible]

z/Linux OS ( SLES12 )

FCP FCP FCP FCP

sda

sdb

sdc

sdd

multipathdevice

Device mapper

OS User[ansible]OS

User[ansible]

OS User[ansible]


FCP FCP FCP FCP

sda

sdb

sdc

sdd

multipathdevice

Device mapper

OS User[ansible]

ansibleの動作例

Storage [ DS8870 ]

SAN switch [ SAN384B-2 ]

Mainflame [ zEC12 ]


LUN

Hypervisor [ zVM 6.4 ]

HBA

FICON

FCP FCP FCP FCP

sda sdb sdc sdd

multipathdevice

Device mapper

LUN

ansible

OS User[ansible]

OS User[ansible]

OS User[ansible]


FCP FCP FCP FCP

sda

sdb

sdc

sdd

multipathdevice

Device mapper

OS User[ansible]

SSH

IFL MEM

inventory

playbook

ansible.cfg

user作成

user作成

user作成

実行コード(python)





今回ansibleを使用するにあたってのポイント

• ansibleで設定する範囲を明確にする

– 共通の設定はクローニングで対応

– 個別の設定はansibleで

• 検証期間も少なかったためシンプルなplaybookを目指す

– ansibleでは条件分岐なども扱えるが、なるべく使わない方針へ

• エクセルの設計書からマクロを使ってvarsファイルを作成

〇〇サーバー#1 {name:test, UID:5000, GID:5000, home:/home/testサーバー名ユーザー名 UID GID ホームディレクトリ

〇〇サーバー#1 test 5000 5000/home/test

〇〇サーバー#2 test2 5001 5001/home/test2〇〇サーバー#2 {name:test2, UID:5001, GID:5001, home:/home/test2設計書(エクセル )

設定ファイル (vars)


構築の流れ

z/Linux OS ( マスターサーバー )

z/Linux OS ( SLES12 )z/Linux OS (

SLES12 )z/Linux OS ( SLES12 )z/Linux OS (

SLES12 )

クローニング兼

ansible実行server変更依頼

共通設定を実施

(syslog、ntpなど)

クローニング

ansibleで個別設定グループ、ユーザー追加

パッケージ導入fcpデバイス有効化、PV、VG、LV、FS作成

ulimits、kernelパラメータ、サービス自動設定ルーティング

ユーザー変更なども楽々

一台一台OS導入は手間なので、共通設定をしたマスターサーバをクローニングするのとansibleで個別設定をする役割


新規環境構築完了

• 2019/03/30 無事z/Linuxサーバー１７9台をansibleで構築し

OSチームとして全環境開放完了

• 現在MW・アプリ事業者による構築・テスト中


z/Linuxにおけるansibleの導入事例他システム事例


• z/Linuxでのansible

導入・構築事例ほぼ無し！

(2018/06月時点)


IBM Z 環境での導入実績が少ない理由• IBM Z 特有のデバイス

– ネットワークデバイス• ×eth → ○qeth

• IBM IBM Z HiperSockets、OSA-Express Fast Ethernet

• 特徴

– ネットワークデバイスが Read,Write,Dataの3つのIOチャネルに分かれている

– SCSIデバイス• ×HBA → ○FCP or ○DASD• 特徴

– LUNへの接続を各デバイスの online/offlineで制御

• s390-tools– LinuxからIBM Z 特有のデバイス用のドライバ類とツール群

• 特有のデバイスに対するハードルが高いのでは。。。– → 取り敢えずやってみよう！


苦労したことs390-toolsの罠

ansibleモジュールの罠

IBM Z独自モジュールへの非対応


s390ツールの罠

• s390ツールで提供のディスクのオンライン/オフラインコマンドのバグ– ディスクオフライン時にオフラインしてほしくないディスクがオフライ

ンされる！

– s390ツールの修正パッチを適用することにより、解決！


LUN 1 LUN 2 LUN 3本来オフラインし

たい


ansibleモジュールの罠

• ボリュームグループが作成されない！

– ボリュームグループを作成する際に/dev/mapper/mpath*のシンボリックリンク先の/dev/dm-*まで辿りボリューム作成を試みる

– しかし、dm-*はカーネル内部でのみ使用される概念のため、ansibleでdm-＊からボリュームグループを作成しようとするとエラーとなる。。。

　

– シンボリックリンクを辿る個所をコメントアウトし解決！


IBM Z独自デバイスへの非対応

• ansibleではIBM Z独自に対応したモジュールがあまりない

– モジュール：操作をスクリプト化したもの、playbookに記述し呼び出す

• shellモジュールにより解決

– shell:実行したいコマンドを記述し、対象サーバー上で実行させるモジュール

– コマンドを実行させるだけなので冪等性が保てなくなるという欠点

name : add useruser - name:taro - UID:1000 - home:/home/taro


それでもスゴイz/Linux＋ansibleパワフルなｚ/Linux大規模環境になるほど柔軟なansible


パワフルなz/Linux

構築中のシステムでは、IBM Z (zEC12)1筐体で・300台以上のz/Linuxサーバー

・20台近くのz/OSサーバー

が稼働しているにも関わらず、

6年間大規模なハードウェアトラブルもなく、

計画停止以外でのシステム停止無く連続稼働中

もしIAサーバーで同等のシステム構成と事業継続性を実現しようとすると、規模(筐体数)と運用保守コスト(機器トラブル・交換対応、保守切れ対応etc...)が莫大に。。。


大規模環境になるほど柔軟なansible

• サーバー179台をトータル26日ほどで作成– 保守・テスト環境14日間– 東本番環境7日– 西本番環境5日

• 解放後、変更依頼にも即座に対応– 個別の設定はvarsを少々手を加えるだけ– configファイルのコピーも楽々


まとめ


IBM Z で稼働するLinuxの強み

• IBM Z (メインフレーム)とは

– 多数のプロセッサユニット(PU)を搭載し、広域クラスタを構成可能

– オペレーティングシステムとして、Linux on IBM Z s, z/OS, z/VM, z/VSE, z/TPFを使用可能

– zEnterprise では、従来からのz/Architectureプロセッサーに加え、POWERおよびx86プロセッサーも搭載

可能となり、全体を統合資源管理ソフトウェアでワークロード管理可能となった。

– 冗長性と信頼性

• 電源、命令回路、冷却機構などほとんどのアーキテクチャが冗長化

• 電源、冷却機構などは動作したままで交換化

• 高価であるが、信頼性の高さがTCO削減となって効果を発揮

• 政府、金融機関、商業、工業などあらゆる場面で長年使用されている実績

• Linuxとは

– オープンソースソフトウェア：広く情報が共有され事例や情報が入手しやすい

– 動作に必要なリソースが少ない軽量サーバー：開発環境を容易に構築して構築前に検証することが出来る

つまり『剛い』ハードで動く『オープンな』Linux


ansibleを使えるz/Linuxの強み

• メインフレーム「IBM Z」の”Z”は、”Zero Down”の” Z ”– 2000年以前のメインフレームは z/OS 専用機だった

– 2008年以降のIBM System z は z/Linux に対応

– 大規模 z/Linux システムでも、ansible を使った柔軟な構築が可能に

つまり『剛い』ハードで『柔く』Linuxを使える

つまり『オープンな』z/Linuxを『柔く』使える


IBM と RedHat と ansible• 2015/01/15　IBM社z/Linux専用メインフレーム LinuxOne(z13)を発表

– 以降z/Linux専用機を相次いで発表(2018/04/10発表の最新メインフレーム z14でもLinuxOneモデル有り )

• 2015/10/16　RedHat社がansible社を買収

• 2018/10/30　IBM社がRedHat社を買収

– 2019年7月9日買収完了

– つまり？

今後z/Linux(IBM)とansible(RedHat)の関係がより密接になるのは明白

– IBM Z 独自のデバイスにも今後対応していくことが期待される

『剛い』ハードで『柔く』Linuxをより使えることが期待される


ｅ

ａ

ｘ

ご清聴いただきありがとうございました。

Documents

上でのansibleの導入と活用事例 · ansibleの要素 ansible inventory playbook ansible.cfg 対象への操作を記述 対象を記述 ansible自体の設定ファイル

上でのansibleの導入と活用事例 · ansibleの要素 ansible inventory playbook ansible.cfg 対象への操作を記述対象を記述 ansible自体の設定ファイル