yamada-hakase’s blog

LinuxなどのOSSやクラウドについて

あらためてEPELリポジトリの使い方をまとめてみた

Linux

1. はじめに

RHEL系ディストリビューションにおける、拡張パッケージのリポジトリ「EPEL」を使っている人は多いだろう。筆者もこれまでの記事で何度か紹介してきた。ところがクラウドでは状況が微妙に異なる。そこで使い方をまとめることにした。

1-1. TL;DR

  • クラウドでは、デフォルトで有効になっていることや、独自のインストールコマンドが提供されていることがある
  • 記事で毎回EPELの使い方を説明するのは無駄

1-2. 前提条件

2. EPELとは

EPELを使う手順は簡単だ。すぐにインストールしたいときは「3. EPELリポジトリを有効にする」に進んでほしい。ここではEPELの概要や使用するうえでの注意事項を説明する。

2-1. もっとも有名なサードパーティー・リポジトリEPEL

EPEL（Extra Packages for Enterprise Linux）は、Fedoraプロジェクトの有志がビルドした、Red Hat Enterprise Linux (RHEL) 系Linuxディストリビューション向けオプションパッケージ群だ。LinuxのメディアやYumリポジトリに含まれないパッケージ入手先の第１候補になる。

EPELのように、ディストリビューション本家以外が提供するリポジトリを「サードパーティー・リポジトリ」と呼ぶ。EPEL以外にも、以下のリポジトリも有名である。

2-2. なぜサードパーティー・リポジトリが必要か？

理由は簡単で「使いたいアプリケーションが標準のYumリポジトリに含まれていない」もしくは「含まれていてもバージョンが古い」からだ。これはディストリビューションのサポート上の理由だ。

  • ディストリビューションベンダーは製品をサポートする責任があるので、標準リポジトリに含めるパッケージを制限している
  • 互換性の問題で、同一メジャーバージョン内で新しいバージョンを取り入れられない

これらの問題は、RHEL7までのSoftware Collections（SCL）や、RHEL8のAppStreamで改善するが、すべての問題が解決するわけではない。

2-2-1. ソースからインストールする？

これらの問題が起きたときソースからビルドする人もいるだろう。ソースコードからのインストールは否定しないが、パッケージ管理ステムのメリットが損なわれる。十分な理由のあるときだけに限ったほうがいいだろう。

ソースからビルドしたときのデメリット

  • 依存関係を保ったシステム管理が難しくなる
  • ソースRPMからビルドしたバイナリRPMはサポート対象外になる

2-2-2. 互換性の話

以下の表は、RHELバージョンごとのkernelとglibcのバージョンをまとめたものだ。同一メジャーバージョン内では、アップデートパッケージを適用してもパッケージのバージョンは変わらない。

ディストリビューション kernel glibc
RHEL6 2.6.32 2.12
RHEL7 3.10.0 2.17
RHEL8 4.18.0 2.28
Amazon Linux 2 4.14 2.26

RPMパッケージは以下のように命名される。kernelやglibcなどのコアコンポーネントの場合、yum updateを実行して変わるのはバージョン以降に付与したリリース番号である。 rpm-version.PNG ここまでしつこく書く理由は、kernelやglibcなどのコアコンポーネントは、アプリケーションの動作保証で極めて重要だからだ。

だから出どころの分からない野良リポジトリを使ってはいけないし、RHEL6用のRPMパッケージをRHEL7にインストールするような強引なことはしてはいけない。

余談 筆者が経験したホラーストーリーがある。とある障害の支援でRHEL6の設定を確かめていたときの出来事だ。いくつかの基本コマンドが動かない。おかしいと思い、以下のコマンドでRed Hat以外のパッケージを探すと、たくさん出てきた。

rpm -qa --qf "%{name} %{vendor}\n"  | grep -v "Red Hat"

それもglibcなどのコアコンポーネントがFedoraやScientific Linuxになっている。それもリリース番号違いでなくバージョン番号違い。本来インストールできないものをnodepsやforceでインストールしたようだ。そんな強引なことをしたら、正常動作しなくて当然だ。逆に動いていたことが不思議でならない。

3. EPELリポジトリを有効にする

EPELを使用するにはepel-releaseパッケージをインストールすればよい。ただし使用するクラウドサービスやLinuxディストリビューションによって以下の注意事項がある。EPELのWebサイトも見てほしい。

3-1. EPELを有効にする（基本）

「クラウドでRHELやCentOSを使うとき」や「オンプレミス環境」ではepel-releaseをインストールする。これが基本になる。

8系Linux OS

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y

7系Linux OS

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y

6系Linux OS

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y

3-2. EPELを有効にする（AWS）

Amazon Linux 2ではEPELを有効にする専用のコマンドが用意されている。AWSでもRHELやCentOSでは、前述の方法を利用する。

sudo amazon-linux-extras install epel

インストールに成功すると「amzn2extra-epel」と「epel」リポジトリが追加される。

$ yum repolist enabled
repo id                    repo name                                   status
amzn2-core/2/x86_64        Amazon Linux 2 core repository                  19791
amzn2extra-docker/2/x86_64 Amazon Extras repo for docker                      28
amzn2extra-epel/2/x86_64★ Amazon Extras repo for epel                         1
epel/x86_64★              Extra Packages for Enterprise Linux 7 - x86 13141+192
repolist: 32961

amzn2extra-epelリポジトリのパッケージ数が1なのが気になる。調べてみるとepel-releaseだけが含まれていた。

repoファイルの定義を確認すると、EPELのミラーサイトを参照しており、クラウド内にAWS独自のミラーサイトがあるわけではない。ログを確認するとcloudfrontから取得している。

[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch★ミラーサイトを取得
failovermethod=priority

3-2. EPELを有効にする（Oracle Cloud Infrastructure）

Oracle Cloud InfrastructureのOracle Linux 7では「ol7_developer_EPEL」という専用のEPELリポジトリが用意してある。そのため追加作業は不要だが、他のOSでは前述の方法を利用する。

EPELリポジトリが有効になっているか、次のコマンドで確認するといいだろう。

$ yum repolist
repo id                         repo name                                 status
ol7_UEKR5/x86_64                Latest Unbreakable Enterprise Kernel Rele   217
ol7_addons/x86_64               Oracle Linux 7Server Add ons (x86_64)       433
ol7_developer/x86_64            Oracle Linux 7Server Development Packages  1349
ol7_developer_EPEL/x86_64★これ Oracle Linux 7Server Development Packages 32336
ol7_ksplice                     Ksplice for Oracle Linux 7Server (x86_64)  7356
ol7_latest/x86_64               Oracle Linux 7Server Latest (x86_64)      18986
ol7_oci_included/x86_64         Oracle Software for OCI users on Oracle L   321
ol7_optional_latest/x86_64      Oracle Linux 7Server Optional Latest (x86 13984
ol7_software_collections/x86_64 Software Collection Library release 3.0 p 14564
repolist: 89546

repoファイルの定義を確認すると、リージョンごとに用意したOracle独自のEPELを参照している。

[ol7_developer_EPEL]
name=Oracle Linux $releasever Development Packages ($basearch)
baseurl=http://yum$ociregion.oracle.com/repo/OracleLinux/OL7/developer_EPEL/$basearch/

ol7_developer_EPELからインストールしたpwgenパッケージを確認すると、ビルドホスト（Build Host）やベンダ（Vendor）が「fedora」ではない。そのためEPELからソースパッケージを取得して再ビルドしていることが分かる。

$ rpm -qi pwgen
Name        : pwgen
Version     : 2.08
Release     : 1.el7
★中略
Source RPM  : pwgen-2.08-1.el7.src.rpm
Build Date  : Tue Aug 14 22:24:07 2018
Build Host  : x86-ol7-builder-01.us.oracle.com　★
Relocations : (not relocatable)
Vendor      : Oracle America　★
URL         : http://sf.net/projects/pwgen
Summary     : Automatic password generation
★以下省略

重要 「EPELからソースパッケージを取得してビルド」という手順を踏んでいることから、EPELとol7_developer_EPELは厳密には同じバイナリではない。またバージョン等のタイムラグの可能性がある。

依存性などの原因でol7_developer_EPELにあるパッケージのインストールに失敗するときは、EPELに切り替えてみよう。

4. さらなるEPELの使いこなし

4-1. EPELの有効化／無効化を切り替える

EPELに限らず追加のリポジトリを使用するときは、「常時有効にする」「一時的に有効にする」の二通りの方法がある。EPELを使い始めたら常時有効にするのが一般的だが、EPELのパッケージを明示的に区別したいときは「一時的に有効にする」ことで区別できる。

常時有効にする yum repolistで表示されるときは有効になっている。またrepoファイルはenabled=1になっている。

一時的に有効にする この方法ではEPELを無効化しておき、必要なときだけ有効化する。

  1. EPELを無効化する。これでyumを実行してもEPELのパッケージは利用できない。
sudo yum-config-manager --disable epel

2.EPELにあるパッケージをインストール／アップデートするときだけ--enablerepoオプションで有効化する。

sudo yum --enablerepo=epel install ＜パッケージ名＞

4-2. トラブルシュート

余力のあるとき執筆予定

5. まとめ

  • 標準リポジトリにないパッケージがあるときはEPELを探そう
  • 野良リポジトリは使わないこと。使うときは人柱覚悟で
  • RPMパッケージの依存性を崩すような強引なことはしないこと
  • AWSではEPELを有効にする独自コマンドが提供されている
  • Oracle Cloud InfrastructureのOracle Linux 7では独自のEPELリポジトリが提供されている

SELinuxとFirewallを有効にしたまま443でsshを受けるように設定する

Linux

1. はじめに

443ポートを使ってssh接続したいことがある。クライアント側はPuTTy/Tera Term/opensshでポート変更するだけでよいが、サーバ側は少し手順が複雑になる。少なくともGUIツール上でポート番号を変えるだけと言うことはない。

また今どきのLinuxは、SELinuxやFirewall（ここではfirewalldやiptablesなどのソフトウェア実装を指している）がデフォルトで有効になっている。

SELinuxやFirewallを有効にするかどうかは別の議論として、有効にして難易度が高くなったときの手段を知っていて損は無いだろう。そこで今回は共に有効にしたまま設定する方法を説明する。

なおSELinuxやFirewallを有効にするかべきかについては、別エントリに書いた。

1-1. 利用環境

当然同じRHEL系ディストリビューションでも同じハズである。

1-2. 設定手順

設定する手順は以下の通り。6系と7系で操作が異なるところは別に書いている。

  1. SELinuxを設定する
  2. Firewallを設定する
  3. sshdを設定する

2. SELinuxを設定する

参考資料

2-1. SELinuxが有効化されているか確認する

現在のステータスを確認するとEnforcingなのでSELinuxは有効になっている。無効のときはPermissiveもしくはDisabledだ。

# getenforce
Enforcing

こちらのコマンドを使うと、もっと細かい情報を表示できる。

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

当然設定ファイルの内容もenforcingになっている。

$ grep ^SELINUX= /etc/selinux/config
SELINUX=enforcing

ヒント SELinuxのモードを永続的に変更するにはOSを再起動する必要がある。しかしsetenforce　0を使うと、動的にpermissiveモードに変更できる。ベアメタルサーバなどOSの再起動に時間のかかるときには便利だ。ただし永続的に変更するには設定ファイル/etc/selinux/configも変更する必要がある。

2-2. SELinuxのポート設定を確認する

SELinuxで443ポートがどのように設定されているか確認する。http_port_tになっているので、Webサーバ（httpd）用に設定されている。

# semanage port -l | grep 443
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000★
pki_ca_port_t                  tcp      829, 9180, 9701, 9443-9447
pki_kra_port_t                 tcp      10180, 10701, 10443-10446
pki_ocsp_port_t                tcp      11180, 11701, 11443-11446
pki_tks_port_t                 tcp      13180, 13701, 13443-13446

2-3. 443ポートをsshd用に変更する

443ポートをsshd用に変更する。

# semanage port -m -t ssh_port_t -p tcp 443

確認するとsshd用に設定が変更されている。

# semanage port -l | grep 443

http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
pki_ca_port_t                  tcp      829, 9180, 9701, 9443-9447
pki_kra_port_t                 tcp      10180, 10701, 10443-10446
pki_ocsp_port_t                tcp      11180, 11701, 11443-11446
pki_tks_port_t                 tcp      13180, 13701, 13443-13446
ssh_port_t                     tcp      443, 22 ★追加された

次にFirewallの設定をする。

3. Firewallを設定する

CentOS 6とCentOS 7/8では、Firewallの設定方法がまったく違うので、それぞれ説明する。

参考資料：

3-1. CentOS 7 / 8（firewalld）の場合

firewalldの設定を確認する

firewalldが起動していることを確認する。activeなので有効化されている。

# systemctl is-active firewalld
active

設定を確認すると、いくつかのポートが開いていることがわかる。しかしhttps/443は開いていない。

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: ssh dhcpv6-client ★
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

firewalldの443ポートを開ける

開いていないので443ポートを開ける。ここでは--add-port=443/tcpでポートを開けている。--add-service=httpsでも結果は同じだが、httpsだと気持ち悪いので、このようにした。

# firewall-cmd --add-port=443/tcp  --permanent --zone=public

リロードして設定を有効化する。

# firewall-cmd --reload
success

再び設定を確認すると443ポートが空いていることがわかる。次はsshdの設定だ。

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: ssh dhcpv6-client
  ports: 443/tcp ★これ
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

3-2. CentOS 6（iptables）の場合

iptablesの設定を確認する

iptablesが起動していることを確認する。このようにズラッと表示されれば起動している。

# service iptables status
テーブル: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
★以下省略

iptablesの設定を確認する。重要なINPUTチェーンだけを表示すると、icmpと22ポートだけが開いていて、443ポートは開いていない。

# iptables -L INPUT --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
2    ACCEPT     icmp --  anywhere             anywhere
3    ACCEPT     all  --  anywhere             anywhere
4    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
5    REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited
★以下省略

iptablesの443ポートを開ける

開いていないので443ポートを開ける。

# iptables -I INPUT 5 -p tcp --dport 443 -j ACCEPT

再び設定を確認すると、INPUTチェーンの最後から2行目に設定が追加され、https/443ポートが開いていることがわかる。

# iptables -L INPUT --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
2    ACCEPT     icmp --  anywhere             anywhere
3    ACCEPT     all  --  anywhere             anywhere
4    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
5    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https★
6    REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

変更内容を保存する。すると設定は/etc/sysconfig/iptablesに保存される。以上でiptablesは終了である。

# service iptables save

4. sshdを設定する

4-1. sshdのリスニングポートを追加する

デフォルトでは22ポートをリスニングしているので、443ポートも追加する。その前に設定ファイルをバックアップする。

# cp -f /etc/ssh/sshd_config /etc/ssh/sshd_config-`date +%Y%m%d`
# sed -i -e "s/\#*Port 22/Port 22\nPort 443/" /etc/ssh/sshd_config

次のように表示されれば、リスニングポートとして22と443が設定されている。

# grep ^Port /etc/ssh/sshd_config
Port 22
Port 443

4-2. sshdを再起動して有効化する

sshdを再起動して設定を有効化する。

# systemctl restart sshd
# service sshd restart

以上で設定はすべて終了した。実際にsshクライアントから接続できるか確認して欲しい。

5. まとめバージョン

コピペで一括実行できるように、まとめバージョンも紹介する。

CentOS 7 / CentOS 8

# 443/tcpをssh用に変更
semanage port -m -t ssh_port_t -p tcp 443

# 443ポートを開放
firewall-cmd --add-port=443/tcp  --permanent --zone=public

# firewalldの設定を有効化
firewall-cmd --reload

# sshdのリスニングポートに443を追加。元ファイルは.bakを付けてバックアップ
sed -i".bak" -e "s/\#*Port 22/Port 22\nPort 443/" /etc/ssh/sshd_config

# sshdを再起動して443ポートを有効化
systemctl restart sshd

CentOS 6

# 443/tcpをssh用に変更
semanage port -m -t ssh_port_t -p tcp 443

# 443ポートを開放
iptables -I INPUT 5 -p tcp -m state --state NEW --dport 443 -j ACCEPT

# iptablesの設定を保存
service iptables save

# sshdのリスニングポートに443を追加。元ファイルは.bakを付けてバックアップ
sed -i".bak" -e "s/\#*Port 22/Port 22\nPort 443/" /etc/ssh/sshd_config

# sshdを再起動して443ポートを有効化
service sshd restart

SELinuxやFirewallは正義か？

Linux

はじめに

今どきのLinuxは、SELinuxやFirewall（ここではfirewalldやiptablesなどのソフトウェア実装を指す）がデフォルトで有効になっていることが多い。これらはインフラ屋にとって難しい存在で、セキュリティ強化をアシストしてくれる一方、これらの機能によって思い通りに操作できないことがある。

そのため

とりあえずSELinuxとFirewallは全部OFF

という人もいれば、

すぐにSELinuxとFirewallを無効にするのはエンジニアとして思考停止。お金をもらうプロフェッショナルならばセキュリティの重要度を考えるべし

という人もいる。楽観主義者と原理主義者が混在している状況だ。

独断と偏見で言わせてもらえば

「状況に応じて判断するべきもので、絶対的にどちらが優れている、という性質のものではない」

本番環境であれば、十分な対策を施したうえでのことではあるが。

他の代替策も考える

たとえばオンプレミスの場合、ルータでACLをがっちり固めていれば、OSのソフトウェアFWは正直なところ必要ないだろう。またクラウドではOS上のソフトウェアFWはトラブルにつながるので、そもそも無効化されていることもある。AWSでは当然それに変わる機能をクラウド側で備えている。

またSELinuxは、万が一潜入されても被害を最小限にできる機能だ。だからWAFを入れるなど、そもそも潜入させない仕組みも重要だろう。さらにその前に「クラウド上にログイン用のssh秘密鍵を置く」といったリテラシーの低い行為を禁止すべきだ（ただし、これは絶対ではない）。

全体のメンバースキルも考える

とても困るのは、全体の状況やメンバーのスキルを考えない開発者で、自分のスキルに自信を持っているが故に、ガチガチに固めたうえ、ろくなドキュメントも無く、それを他人にも押しつけるケースだ。

これらを押しつけた結果、SELinuxやfirewalld/iptablesの操作が難しく開発・構築フェーズの生産性が上がらない。また運用フェーズで間違ったオペレーションをしてしまいトラブルが発生する。

さらに最悪なのは運用フェーズで何かトラブルがあっても、SELinuxやfirewalld/iptablesに精通しているメンバーが不在で、設定した本人以外はどうにもできないという状況だ。

セキュリティも重要だが、身の丈を超えたものは、他のトラブルを招く。

運用トラブルいろいろ

なんだか本題のSELinuxとFirewallから本題がそれてきた気がするが、このまま突っ走ることにする（笑）。

この手のトラブルはセキュリティ以外にもある。筆者は直接の当事者では無かったが、以下のような経験をしたことがある。

  1. 突如Webサーバが停止。Webにページアクセスできず
  2. 運用担当者がservice httpd statusで確認したところ停止していた
  3. 急いでservice httpd startでWebサーバ起動。しかし解決せず
  4. 運用手順書を見ると、独自の起動用スクリプトがあることを発見。それを使っても起動できず
  5. 最終的な原因はrpmでインストールする標準のhttpd以外に、別ディレクトリにソースコードからインストールしたWebサーバがあったこと。起動／停止には独自スクリプトを使う必要があったが、service httpd startでWebサーバを起動してしまったためにポートを確保。そのため独自の起動用スクリプトを使っても起動できなかった

ここから得られる反省点は、標準および標準化に対する認識が不足していたこと。標準のhttpd以外にhttpdがあるならば、標準のhttpdは削除しておくべきだし、依存性で削除できないならば、起動スクリプトを差し替えてワーニングのメッセージを出すのも一つだろう。

間違う可能性があるならば、それを徹底的に排除する対策をとることも重要だ。

利用者／運用者の目線を持つこと

一般的なエンタープライズシステムは、開発期間と比べて運用期間ははるかに長い。はるかに長いゆえ、開発時のことをよく知っていた運用担当者がいなくなり、保持しているノウハウも低下する。たとえ、いたとしても記憶は薄まる。

また開発者はそのとき注力しているため十分な知識があるが、利用者／運用者はそれほどの知識を持たない。

このことを十分に理解せず

「エンジニアならば、この程度のことはできるだろう」

という高い目線で設計やドキュメントすると、利用者／運用者が使いこなせず、トラブルや問い合わせ頻発というのも、ありがちな話だ。

まとめ

全然まとまっていないが、全体を俯瞰できる高い視点に立ち、ナルシストに陥らず、運用までを考慮することが重要だろう。なんだか、タイトルと全然違う内容になっている気がするけれど、ごめんなさい。

  • 全体を考えたバランス感
  • 自分だけで無く、運用担当者を含めた企業全体のリテラシーを考えた設計
  • 標準への順守。間違いづらい設計

OCI Computeでブロック・ボリュームをiSCSIでアタッチする

Linux Oracle Cloud

1. はじめに

ブロック・ボリュームのアタッチ方法（アタッチメント・タイプ）には「準仮想化（Paravirtualized）」と「iSCSI」がある。以前書いた「 OCI Computeでブロックボリュームをマウントする」では、手順が簡単な「準仮想化」を使用している。

しかし、マニュアル「Block Volume Performance」には「パフォーマンスSLAの対象になるのはiSCSIアタッチメントだけ」と書いてある。

Block Volume performance SLA for IOPS per volume and IOPS per instance applies to iSCSI volume attachments only, not to paravirtualized attachments.

以前テストしたときは、それほどパフォーマンスは変わらなかった。しかしながらSLAの条件なので、iSCSIについても説明する。

なお、もうひとつのパフォーマンス指標である帯域幅はシェイプに依存するので、アタッチメント・タイプとは関係ない。

1-1. 対象環境

1-2. 参考資料

2. iSCSIアタッチメントの基本

Oracle Cloud Infrastructureでブロック・ボリュームは外部ストレージに存在する。そのときインスタンスからブロック・ボリュームを接続する方法として、「準仮想化」と「iSCSI」がある。それぞれの違いを説明する。

2-1. 準仮想化とiSCSIの違い

詳しい技術的な違いは置いておくとして、覚えるべきは次の3点だ。

  • ベアメタル・インスタンスが利用できるのは「iSCSI」に限られる
  • パフォーマンスSLAが適用されるのは「iSCSI」に限られる
  • 「準仮想化」のほうが利用手順が簡単

2-2. 利用手順の違い

次の表は、新しいブロック・ボリュームの使用手順を「準仮想化」と「iSCSI」で比較したものだ。iSCSIでは「3.iSCSIコマンド等でアタッチ」の手順が増える。

手順 準仮想化 iSCSI
1.ブロック・ボリュームの作成 ○ ○
2.管理コンソールやCLIでブロック・ボリュームのアタッチ ○ ○
3.iSCSIコマンド等でアタッチ 不要 ○
4.ディスク・パーティションの作成 ○ ○
5.ファイル・システムの作成 ○ ○
6.mountコマンドでマウント ○ ○

アタッチは2回あり、それぞれで意味が違う。手順2のアタッチは「ケーブルの接続」に相当し、手順3のアタッチは「OSからボリュームの認識」に相当する。

また手順3のアタッチには、次の3つの実現方法がある。

  • iSCSIコマンドで手動アタッチする
  • oci-iscsi-configで手動アタッチする
  • ocidサービスで自動アタッチする

どれを使っても結果は同じだが、ocidサービスは自動的にブロック・ボリュームを検出＆アタッチするので便利だ。ただし、OSの種類やバージョンによっては使えないことがある。

2-3. デタッチも気をつける

利用開始したブロック・ボリュームをデタッチする機会は少ない。しかし「ブロック・ボリュームのサイズをオフライン拡張する」「完全に一貫性のあるバックアップを取得する」「インスタンスやボリュームをリカバリーする」「シェイプを変更する（※）」などのメンテナンス作業ではデタッチが必要になる。

※必須ではないが推奨

次の表はデタッチの手順だ。アタッチの逆順になる。ocidサービスで自動アタッチしているときでも、デタッチはコマンドを実行する必要があるので注意すること。

手順 準仮想化 iSCSI
1.mountコマンドでアンマウント ○ ○
2.iSCSIコマンド等でデタッチ 不要 ○
3.管理コンソールやCLIでブロック・ボリュームのデタッチ ○ ○

3. iSCSIアタッチする

もっとも基本的な2種類のアタッチ方法を説明する。oci-iscsi-configは便利コマンドなので「6. oci-iscsi-configの使い方」で説明する。

  • iSCSIコマンドで手動アタッチする
  • ocidサービスで自動アタッチする

3-1. iSCSIコマンドでアタッチする

はじめに、iSCSIコマンド利用したアタッチ方法を説明する。こちらがオーソドックスな方法である。

  1. 管理コンソールでブロック・ボリュームをアタッチする。 iscsi05.PNG
  2. アタッチしたブロック・ボリュームを表示する。右の「・・・」をクリックして「iSCSI Commands & Information」を選択する。 iscsi03.PNG
  3. アタッチ／デタッチするコマンドが表示されるのでコピーする。 iscsi06.PNG
  4. OSにログインして、コピーしたコマンドを実行する。「iSCSI IP address:iSCSI port」はインスタンスによって異なることがあるので使い回さないこと。
sudo iscsiadm -m node -o new -T <volume IQN> -p <iSCSI IP address>:<iSCSI port>
sudo iscsiadm -m node -o update -T <volume IQN> -n node.startup -v automatic
sudo iscsiadm -m node -T <volume IQN> -p <iSCSI IP address>:<iSCSI port> -l

5.iSCSIコマンドに成功すると、アタッチしたボリュームが表示される。コマンドを実行するのは初回だけで、起動／停止しても再実行する必要は無い。

# iscsiadm -m session
tcp: [1] 169.254.2.2:3260,1 iqn.2015-12.com.oracleiaas:a37bb084-07c4-4a21-b73c-e0d4b2894037 (non-flash)

3-2. ocidサービスでアタッチする

ocidサービスを起動した状態でブロック・ボリュームを管理コンソールなどでアタッチすると、iSCSIコマンドを実行しなくても自動的にアタッチできる。

なお、ocidサービスを利用できるのは、Oracle Linux 7以降のバージョンに限られる。

  1. ocidサービスの状態を確認する。
systemctl status ocid
● ocid.service - Oracle Cloud Infrastructure utilities daemon
   Loaded: loaded (/etc/systemd/system/ocid.service; disabled; vendor preset: enabled)
   Active: ★inactive (dead)★
● ocid.service - Oracle Cloud Infrastructure utilities daemon
   Loaded: loaded (/etc/systemd/system/ocid.service; disabled; vendor preset: enabled)
   Active: ★active (running)★ since 土 2020-04-11 03:12:19 JST; 2s ago
 Main PID: 30244 (python2.7)
   CGroup: /system.slice/ocid.service
           └─30244 python2.7 /usr/libexec/ocid

2.ocidサービスが停止しているときは起動する。

systemctl start ocid

3.自動起動を有効化する。

# systemctl enable ocid
Created symlink from /etc/systemd/system/multi-user.target.wants/ocid.service to /etc/systemd/system/ocid.service.

# systemctl list-unit-files | grep ocid
ocid.service                                  enabled★自動起動有効

4.管理コンソールでブロック・ボリュームをアタッチする。

5.オペレーティング・システムから認識できるようになるまで2，3分かかる。/var/log/messagesに次のようなログが表示されたら完了だ。ocidによる自動化は、単純に省力化できるだけで無く、カスタムイメージやオートスケールを使用するときに役に立つ。

# tail -f /var/log/messages
eiaas:d6557dec-6f18-4432-acfa-f8335e5d3e52, portal: 169.254.2.2,3260] through [iface: default] is operational now
Sep  9 09:47:58 ol7srv3 kernel: scsi 3:0:0:0: RAID              IET      Controller       0001 PQ: 0 ANSI: 5
Sep  9 09:47:58 ol7srv3 kernel: scsi 3:0:0:0: Attached scsi generic sg1 type 12
Sep  9 09:47:59 ol7srv3 kernel: scsi 3:0:0:2: Direct-Access     ORACLE   BlockVolume      1.0  PQ: 0 ANSI: 6
Sep  9 09:47:59 ol7srv3 kernel: sd 3:0:0:2: Attached scsi generic sg2 type 0
Sep  9 09:47:59 ol7srv3 kernel: sd 3:0:0:2: [sdb] 104857600 512-byte logical blocks: (53.7 GB/50.0 GiB)
Sep  9 09:47:59 ol7srv3 kernel: sd 3:0:0:2: [sdb] 4096-byte physical blocks

ocidによる自動アタッチは、こちらの記事を参考にさせていただきました。

4. アタッチしているiSCSIを確かめる

もっとも一般的な方法は、次のコマンドだ。準仮想化のときは何も表示されない。

#  iscsiadm -m session
tcp: [1] 169.254.2.2:3260,1 iqn.2015-12.com.oracleiaas:99ccef68-e6de-4f3b-bc0f-xxxxxxxxxxxx (non-flash)

7系以降に限られるが、便利なのはlsblkの-Sオプションだ。iSCSIでアタッチしているときは一番右に表示される。

# lsblk -S
NAME HCTL       TYPE VENDOR   MODEL             REV TRAN
sdb  3:0:0:2    disk ORACLE   BlockVolume      1.0  iscsi
sda  2:0:0:1    disk ORACLE   BlockVolume      1.0

同様に7系ではoci-iscsi-configコマンドも使える。コマンドの使い方は--helpでどうぞ。

# oci-iscsi-config -s
Warning:
For full functionality of this utility the ocid service must be running
The administrator can start it using this command:
    sudo systemctl start ocid.service

Currently attached iSCSI devices:

Target iqn.2015-12.com.oracleiaas:99ccef68-e6de-4f3b-bc0f-xxxxxxxxxxxx
   Persistent portal:    169.254.2.2:3260
      Current portal:    169.254.2.2:3260
               State:    LOGGED_IN
     Attached device:    sdb
                Size:    300G
    File system type:    Unknown
          Mountpoint:    Not mounted

Need OCI services to display available devices.

5. iSCSIデタッチする

「2-3. デタッチも気をつける」で説明したように、管理コンソールでブロック・ボリュームデタッチするときは、先にiSCSIコマンドでデタッチする必要がある。

ocidサービスで自動アタッチしているときでも、デタッチするときは手動でコマンドを実行する必要があるので注意すること。

  1. ocidサービスが起動していると自動アタッチされるのでサービスを停止する。
systemctl status ocid
systemctl stop ocid

2.ボリュームをアンマウントする。

umount ＜マウントポイント＞

3.アタッチしたときと同様な手順で、こんどはデタッチのコマンドをコピーする。 iscsi08.PNG

4.コピーしたコマンドを実行する。複数ブロック・ボリュームをアタッチしているときは、それぞれで実行する。

sudo iscsiadm -m node -T <volume IQN> -p <iSCSI IP address>:<iSCSI port> -u
sudo iscsiadm -m node -o delete -T <volume IQN> -p <iSCSI IP address>:<iSCSI port>

5.次のように何も表示されなければデタッチに成功している。

$ iscsiadm -m session
iscsiadm: No active sessions.

6.管理コンソールでブロック・ボリュームをデタッチする。以上で終了だ。

6. oci-iscsi-configの使い方

oci-iscsi-configは、oci-utilsパッケージに含まれるiSCSIユーティリティーだ。iscsiadmを使わずに簡単にアタッチ／デタッチができる。詳しくはmanを見るとして、基本的な使い方を説明する。なおroot権限で実行する必要がある。

6-1. oci-iscsi-configでアタッチする

  1. 管理コンソールからブロック・ボリュームの「・・・」をクリックして「iSCSI Commands & Information」を選択する。ここで[VOLUME IQN]をコピーする。 iscsi07.PNG

  2. oci-iscsi-configコマンドでアタッチする。ワーニングは無視してよい。

# oci-iscsi-config -a ＜コピーしたVOLUME IQN＞
Warning:
For full functionality of this utility the ocid service must be running
The administrator can start it using this command:
    sudo systemctl start ocid.service

Target iqn.2015-12.com.oracleiaas:a37bb084-07c4-4a21-b73c-e0d4b2894037 is already attached.

3.次のコマンドを実行するとアタッチされているボリュームが表示される。

# oci-iscsi-config -s
Currently attached iSCSI devices:

Target iqn.2015-12.com.oracleiaas:a37bb084-07c4-4a21-b73c-e0d4b2894037
   Persistent portal:    169.254.2.2:3260
      Current portal:    169.254.2.2:3260
               State:    LOGGED_IN
     Attached device:    sdb
                Size:    50G
    File system type:    Unknown
          Mountpoint:    Not mounted

Need OCI services to display available devices.

6-2. oci-iscsi-configでデタッチする

  1. ocidサービスが起動していると自動アタッチされるのでサービスを停止する。
systemctl status ocid
systemctl stop ocid

2.oci-iscsi-configコマンドでデタッチする。ワーニングは無視してよい。

# oci-iscsi-config -d ＜コピーしたVOLUME IQN＞
Warning:
For full functionality of this utility the ocid service must be running
The administrator can start it using this command:
    sudo systemctl start ocid.service

Updating ignore file: ['iqn.2015-12.com.oracleiaas:a37bb084-07c4-4a21-b73c-e0d4b2894037']

3.確認するとDetachedと表示される。

# oci-iscsi-config -s
Warning:
For full functionality of this utility the ocid service must be running
The administrator can start it using this command:
    sudo systemctl start ocid.service

Currently attached iSCSI devices:
Error: Local iSCSI info not available.
List info from Cloud instead(No boot volume).

Need OCI services to display available devices.
Detached devices:

Target iqn.2015-12.com.oracleiaas:a37bb084-07c4-4a21-b73c-e0d4b2894037
              Portal:    169.254.2.2:3260
               State:    Detached★

7. おわりに

いままで自分ではあまり使っていないiSCSIアタッチだが、実際にやってみると簡単なことがわかる。マニュアルには、他にもいろいろ書かれているのでどうぞ。

  • ブロック・ボリュームのアタッチ方法には「準仮想化」と「iSCSI」がある
  • ベアメタル・インスタンスが利用できるのは「iSCSI」に限られる
  • パフォーマンスSLAが適用されるのは「iSCSI」に限られる
  • 「準仮想化」のほうが利用手順が簡単
  • iSCSIでアタッチするには「iSCSIコマンドで手動実行する方法」と「ocidサービスによる自動実行する方法」がある
  • iSCSIでデタッチするときには、管理コンソールでデタッチする前にコマンドでデタッチを実行する必要がある

OCI Computeでブロックボリュームをマウントする（LVM不使用編）

Linux Oracle Cloud

1. はじめに

以前に書いた以下のエントリでは、追加したブロックボリュームをLVM（論理ボリュームマネージャー）で構成した。

しかしクラウドや仮想サーバー環境では既存のボリュームを簡単に拡張できるので、使わないことも多い。そこで今回はLVMを使用しない方法を説明する。

既存のボリュームを拡張する方法

Oracle Cloud Infrastructureでボリュームを拡張するには以下の方法がある。この中で1番目の方法を説明する。

  • オフラインにした既存のボリュームを拡張する
  • ボリュームのバックアップを、より大きなサイズのボリュームにリストアする
  • 既存のボリュームを、より大きなサイズのボリュームにクローンする

2. 前提条件

前回の補足的な位置づけなので、ブロックボリュームは作成＆アタッチ済みで、「5-2. ディスクパーティションを作成する」以降の差分だけを書くことにする。

3. 追加したブロックボリュームを使えるように構成する

3-1. パーティション構成を確認する

追加したブロックボリュームを確認する。すると/dev/sdbとして追加され、コンシステンス・デバイス・パス/dev/oracleoci/oraclevdbとして定義されていることがわかる。

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0  512G  0 disk
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi
# ll /dev/oracleoci/oraclevd*
lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevda -> ../sda
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda1 -> ../sda1
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda2 -> ../sda2
lrwxrwxrwx. 1 root root 7 Jul 16 19:13 /dev/oracleoci/oraclevda3 -> ../sda3
lrwxrwxrwx. 1 root root 6 Jul 16 19:13 /dev/oracleoci/oraclevdb -> ../sdb

3-2. ディスクパーティションを作成する

LVMは使用しないので、LVMフラグを付けずに作成する。ここではコンシステンス・デバイス・パスを指定しているが/dev/sdbでもよい。

# parted -s -a optimal /dev/oracleoci/oraclevdb \
   mklabel gpt \
   mkpart primary 0% 100%

パーティション情報を確認するとsdb1が定義されていることがわかる。

# parted /dev/oracleoci/oraclevdb print
Model: ORACLE BlockVolume (scsi)
Disk /dev/sdb: 550GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  550GB  550GB               primary
# lsblk -o +UUID
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT UUID
sdb      8:16   0  512G  0 disk
└─sdb1   8:17   0  512G  0 part            c31941dc-9bae-4680-9c35-8f195b0db30d
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]     d2f67c75-3f12-4abb-9c5a-ae8c23426d7c
├─sda3   8:3    0 38.4G  0 part /          666196a2-64e0-4535-a3f8-7d746a37d900
└─sda1   8:1    0  200M  0 part /boot/efi  6F4C-7CE8

3-3. ファイルシステムを作成する

ファイルシステムをxfsでフォーマットする。ext4のときには、代わりにmkfs.ext4を指定する。

# mkfs.xfs /dev/oracleoci/oraclevdb1
meta-data=/dev/oracleoci/oraclevdb1 isize=256    agcount=4, agsize=33554304 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=134217216, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=65535, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

3-4. 次の手順は

残るは以下の作業である。この部分は同じなので「5-7. ブロックボリュームをマウントする」以降を参照のこと。

4. コピペ用まとめバージョン

コンシステンス・デバイス・パス使用の有無によって一番違うのは/etc/fstabである。使用しないときは必ずUUIDを指定する。

コンシステンス・デバイス・パス使用

# パーティション作成
parted -s -a optimal /dev/oracleoci/oraclevdb mklabel gpt mkpart primary 0% 100%

# ファイルシステム作成
mkfs.xfs /dev/oracleoci/oraclevdb1

# マウントポイント作成
mkdir /mnt/vol01
chown opc:opc /mnt/vol01

# /etc/fstab元ネタ。次の行を/etc/fstabの末尾に追加する
echo "/dev/oracleoci/oraclevdb1    /mnt/vol01 xfs defaults,_netdev,nofail 0 2"

コンシステンス・デバイス・パス不使用

# パーティション作成
parted -s -a optimal /dev/sdb1 mklabel gpt mkpart primary 0% 100%

# ファイルシステム作成
mkfs.xfs /dev/sdb1

# マウントポイント作成
mkdir /mnt/vol01
chown opc:opc /mnt/vol01

# /etc/fstab元ネタ。次の行を/etc/fstabの末尾に追加する
echo UUID= ; lsblk -o +UUID | grep sdb1 | awk '{print $NF}' ; echo "    /mnt/vol01 xfs defaults,_netdev,nofail 0 2"

OCI Computeでブロックボリュームをマウントする

Linux Oracle Cloud

マニュアルやチュートリアルにも書かれているテーマだけれど、その内容がイマイチなので、ここで整理したい。

0. 対象環境

1. なぜブロックボリュームのマウントについて書くのか

ブロックボリュームのマウントはCompute（IaaS）を利用する際に、もっとも基本的な操作の1つである。ところがOCIのマニュアルやチュートリアルを読むと、心配になるほど貧弱な記述であることに気付く。

具体的には

  • OCIのブロックボリュームはgptだし、最大32TBまで可能なのに、なぜfdisk使ってるの？
  • 今どき論理ボリュームマネージャ（LVM）は使わないの？

追記：クラウドではボリュームを簡単に拡張できるので、LVMを使わないことも多い。fdiskのgpt対応については、Oracle Linux 7でもexperimental（実験的）フェーズなのでpartedを推奨。

さらに「チュートリアル : Oracle Cloud Infrastructure を使ってみよう」の「ブロック・ボリュームをインスタンスにアタッチする - Oracle Cloud Infrastructureを使ってみよう（その4）」では、下記のように作成中でごまかしている始末。うーん。

3. (オプション) ボリュームのフォーマットおよびマウント(作成中) 以下のように修正された。

その後、実際にボリューム上にデータを配置する際には、各OS上で適切なファイルシステムを構築して利用してください。

ということで、次にわたしが理想的と考えている方法を説明する。

今回は「Oracle Linux 6」「Oracle Linux 7」「Oracle Linux 8」を使用しているが、CentOS 6/7/8は当然のこと、RHEL系のディストリビューションでも同じハズだ。さらに純粋なLinuxコマンド部分だけについて言えば、AWSやAzureでも通用する内容にしたつもりである。

またLVMを使わない方法は、別エントリーに差分だけを書くことにする。クラウドではLVMを使わないほうが一般的だ。

2. デフォルトのディスク情報を確認する

実際にコマンドを実行する箇所ではOracle Linux 7を使用する。7と8では、ほぼ同じ操作だ。またOracle Linux 6は大きく違うときに限り併記する。

2-1. ディスク構成を確認する

まずデフォルトのディスク構成を確認する。するとブートボリュームとして/dev/sdaがあり、UEFI構成になっていることがわかる。

# lsblk -o +UUID
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT UUID
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]     8c83c999-ef07-40b5-b001-9658556502d3
├─sda3   8:3    0 38.4G  0 part /          eb7fd29b-a114-4e5e-8926-a6f4a541d605
└─sda1   8:1    0  200M  0 part /boot/efi  52AE-1880

2-2. パーティション構成を確認する

続いてパーティション構成を確認する。するとパーティションテーブルは従来のMBRではなくgptになっている。またファイルシステムは、Oracle Linux 7＝xfs、Oracle Linux 6＝ext4になっている。

表示だけならばfdisk -lで確認できるが、fdiskのgpt対応はexperimentalフェーズなので推奨しない。partedやgdiskが推奨である。とくにpartedは対話的に実行しない方法が提供されているのでオススメである。gdiskはgpt対応のfdiskクローン。

Oracle Linux 7 / 8：

# parted -l
Model: ORACLE BlockVolume (scsi)
Disk /dev/sda: 50.0GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt★
Disk Flags:

Number  Start   End     Size    File system     Name                  Flags
 1      1049kB  211MB   210MB   fat16           EFI System Partition  boot
 2      211MB   8801MB  8590MB  linux-swap(v1)
 3      8801MB  50.0GB  41.2GB  xfs★

Oracle Linux 6：

# parted -l
Model: ORACLE BlockVolume (scsi)
Disk /dev/sda: 50.0GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt★

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  211MB   210MB   fat16                 boot
 2      211MB   8801MB  8590MB  linux-swap(v1)
 3      8801MB  50.0GB  41.2GB  ext4★

また上記の結果からもわかるが、pvsで確認すると、論理ボリュームマネージャ（以降LVM）が構成されていないことがわかる。

# pvs
★何も表示されない★

3. コンシステンス・デバイス・パスとは

ブロックボリュームをマウントする方法には、デバイス名として従来通りUUIDを指定する方法と、コンシステンス・デバイス・パスを指定する方法がある。コンシステンス・デバイス・パスは以下の条件を満たすときに使用できる。

  • Oracle-Provided Image
  • Linuxベースのイメージ
  • 2018年11月以降のイメージで2019月1月11以降に再起動している

筆者が調べた限りでは、LVM環境ではコンシステンス・デバイス・パスは利用できなかった。パーティション内の論理ボリュームを認識できないためだと思われる（2019/5）。

3-1. リブートするとデバイス名が変わる問題

Linuxでリモートストレージを使用する場合、デバイス追加などが発生すると、再起動時にデバイス名が変わる可能性がある。そのために導入されたのがコンシステンス・デバイス・パスだ。コンシステンス・デバイス・デバイス名はリブートしても変わらないので、安心して/etc/fstabに指定できる。

また従来の方法でもUUIDを指定すれば、リブートによるデバイス名変更の影響は受けない。コンシステンス・デバイス・パスは、UUIDよりも人間にリーダブルな方法と考えていいだろう。ただし制限事項もあるので、どちらを利用するかは使用しているイメージやLVM使用の有無、既存環境との互換性などを考慮したうえで選択して欲しい。

3-2. コンシステンス・デバイス・パスの確認方法

コンシステンス・デバイス・パスはブロックボリュームアタッチ時に指定でき、管理コンソールでも確認できる。以下のようなDevice Pathになっているときは/etc/fstabで/dev/oracleoci/oraclevdc1のようなデバイス名を使用できる。 consistentpath.jpg

3-3. 従来のUUIDを使用する

今回はLVMを使用するので従来のUUIDを使った方法を主体に説明する。コンシステンス・デバイス・パスについては補足にとどめる。マニュアルの参考箇所は以下の通り。

4. インスタンスにブロックボリュームを追加する

実際にブロックボリュームを作成し、Computeインスタンスにアタッチする。アタッチとは、オンプレミスで言うところの「ケーブル接続」という感覚に近い。

4-1.ブロックボリュームを作成する

Computeと同じADにブロックボリュームを作成する。今回はvolume-phx-ad-t-orcl01-ol7というブロックボリュームを作成する。

4-2. ブロックボリュームをアタッチする

コンソールやCLIなどで、以下の条件でボリュームをアタッチする。

  • ATTACHMENT TYPE : Paravirtualized
  • BLOCK VOLUE NAME: volume-phx-ad-t-orcl01-ol7
  • DEVICE PATH: /dev/oracleoci/oraclevdb
  • IN-TRANSIT ENCRYPTION: not check(disable)
  • Access: Read/Write

ヒント ブロックボリュームのアタッチ方法には、ParavirtualizedとiSCSIの2種類がある。現在払い出すインスタンスは「仮想マシンはParavirtualizedもしくはiSCSI」「ベアメタルはiSCSI」を使用できる。

Paravirtualizedのほうが手順は簡単だが、iSCSIのほうがIOPS性能に優れている。どちらを使用するかは、以下のマニュアルを読んで決めて欲しい。

「iSCSIのほうが性能がいい」ということだったが、筆者がテストしたところ大きな差はみられなかった。ただしiSCSI接続は、Enterprise SLA(Performance)を適用する前提条件になっている。

手順は以下のエントリを参照のこと。

4-3. 追加したブロックボリュームを確認する

再びディスク情報を確認すると/dev/sdbがアタッチされている。

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0   50G  0 disk★追加したボリューム
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi

またコンシステンス・デバイス・パスを指定したので、/dev/sdbに対し/dev/oracle/oraclevdbというシンボリックリンクが作成されている。

# ls -l /dev/oracle*
total 0
lrwxrwxrwx. 1 root root 6 May 13 04:22 oraclevda -> ../sda
lrwxrwxrwx. 1 root root 7 May 13 04:22 oraclevda1 -> ../sda1
lrwxrwxrwx. 1 root root 7 May 13 04:22 oraclevda2 -> ../sda2
lrwxrwxrwx. 1 root root 7 May 13 04:22 oraclevda3 -> ../sda3
lrwxrwxrwx. 1 root root 6 May 13 04:37 oraclevdb -> ../sdb★

5. 作成したブロックボリュームをインスタンスで使えるようにする

今回はアタッチしたボリュームを以下の構成で設定する。

/dev/sdbの代わりにコンシステンス・デバイス・パス（/dev/oracleoci/oraclevdb）も利用できる。ただしLVMでは使用できないので、今回は/dev/sdbを使用する。

5-1. 手順全体の流れ

手順全体は以下の通り。LVMを使うと、それなりに手順が複雑になる。逆にLVMを使わないときは、2から4の手順を省略できる。

  1. ディスクパーティションを作成する
  2. LVMのPV（物理ボリューム）を作成する
  3. LVMのVG（ボリュームグループ）を作成する
  4. LVMのLV（論理ボリューム）を作成する
  5. ファイルシステムを作成する
  6. インスタンスにマウントする

LVMについては一定の知識が必要になる。詳細は以下のマニュアルを参考にすること。

5-2. ディスクパーティションを作成する

partedを使ってLVM用のディスクパーティションを作成する。/dev/sdbに対し、gptフラグとLVMフラグを付け、ディスクの全サイズを割り当てている。

またset 1の行は「1番目のパーティションにLVMのフラグを付ける」という意味である。そのためLVMを使用しないときは最後の"set 1 lvm on"が不要である。partedの詳細はpartedチートシートなどを参照のこと。

1回実行バージョン （末尾の\は改行を入れる目的で付けている。削除して1行で実行してもよい）

# parted -s -a optimal /dev/sdb \
   mklabel gpt \
   mkpart primary 0% 100% \
   set 1 lvm on

分割実行バージョン

parted /dev/sdb mklabel gpt
parted -a optimal /dev/sdb mkpart primary 0% 100%
parted /dev/sdb set 1 lvm on

再び確認するとパーティションが作成されている。

# parted /dev/sdb print
Model: ORACLE BlockVolume (scsi)
Disk /dev/sdb: 53.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  53.7GB  53.7GB               primary  lvm

次の手順は省略してよいが、作成したパーティションに対応した、コンシステンス・デバイス・パスも作成されていることがわかる。

# ls -l /dev/oracleoci/oraclevd*
lrwxrwxrwx. 1 root root 7 May 13 07:39 /dev/oracleoci/oraclevdb1 -> ../sdb1lrwxrwxrwx. 1 root root 6 May 13 04:22 /dev/oracleoci/oraclevda -> ../sda
lrwxrwxrwx. 1 root root 7 May 13 04:22 /dev/oracleoci/oraclevda1 -> ../sda1
lrwxrwxrwx. 1 root root 7 May 13 04:22 /dev/oracleoci/oraclevda2 -> ../sda2
lrwxrwxrwx. 1 root root 7 May 13 04:22 /dev/oracleoci/oraclevda3 -> ../sda3
lrwxrwxrwx. 1 root root 6 May 13 07:01 /dev/oracleoci/oraclevdb -> ../sdb
lrwxrwxrwx. 1 root root 7 May 13 07:39 /dev/oracleoci/oraclevdb1 -> ../sdb1★これ

5-3. LVMの物理ボリュームを作成する

作成したパーティション/dev/sdb1にLVMの物理ボリューム（PV）を作成する。

# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.

pvsで物理ボリューム確認すると、物理ボリューム/dev/sdb1が作成されている。

# pvs
  PV         VG Fmt  Attr PSize   PFree
  /dev/sdb1     lvm2 ---  <50.00g <50.00g

5-4. LVMのボリュームグループを作成する

ボリュームグループ（VG）vg01を作成し、前のステップで作成した物理ボリューム/dev/sdb1を割り当てる。

# vgcreate vg01 /dev/sdb1
  Volume group "vg01" successfully created

vgsでボリュームグループを確認すると、ボリュームグループvg01が作成され、空き容量50GBになっている。

# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg01   1   0   0 wz--n- <50.00g <50.00g

5-5. LVMの論理ボリュームを作成する

論理ボリューム（LV）lv_dataを作成し、ボリュームグループvg01の全サイズを割り当てる。サイズを指定するときはlvcreate -L 20G -n lv_data vg01のように指定する。

# lvcreate -l 100%FREE -n lv_data vg01
  Logical volume "lv_data" created.

lvsで論理ボリューム確認すると、論理ボリュームlv_dataが作成されている。

# lvs
  LV      VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_data vg01 -wi-a----- <50.00g

再びボリュームグループを確認すると、lv_dataに全サイズを割り当てたため、空きはゼロになっている。

# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg01   1   1   0 wz--n- <50.00g    0 ★VFreeがゼロになっている

また以下のデバイスファイルが作成されている。/dev/vg01/lv_dataと/dev/mapper/vg01-lv_dataは共に/dev/dm-0のシンボリックリンクである。

# ls -l /dev/vg01/lv_data
lrwxrwxrwx. 1 root root 7 May 13 07:39 /dev/vg01/lv_data -> ../dm-0

# ls -l /dev/mapper/vg01-lv_data
lrwxrwxrwx. 1 root root 7 May 13 07:39 /dev/mapper/vg01-lv_data -> ../dm-0

今回はpvsやvgs、lvsを使用しているが、pvdisplay、vgdisplay、lvdisplayなどを使用すると、もっと詳しい情報を表示できる。

/dev/oracleoci/oraclevd*を確認すると、論理ボリュームlv_dataに対応したデバイスファイルが追加されていない。そのためコンシステンス・デバイス・パスはLVMに対応していないと判断した。

# ls -l /dev/oracleoci/oraclevd*
lrwxrwxrwx. 1 root root 7 May 13 07:39 /dev/oracleoci/oraclevdb1 -> ../sdb1lrwxrwxrwx. 1 root root 6 May 13 04:22 /dev/oracleoci/oraclevda -> ../sda
lrwxrwxrwx. 1 root root 7 May 13 04:22 /dev/oracleoci/oraclevda1 -> ../sda1
lrwxrwxrwx. 1 root root 7 May 13 04:22 /dev/oracleoci/oraclevda2 -> ../sda2
lrwxrwxrwx. 1 root root 7 May 13 04:22 /dev/oracleoci/oraclevda3 -> ../sda3
lrwxrwxrwx. 1 root root 6 May 13 07:01 /dev/oracleoci/oraclevdb -> ../sdb
lrwxrwxrwx. 1 root root 7 May 13 07:39 /dev/oracleoci/oraclevdb1 -> ../sdb1

5-6. ファイルシステムを作成する

Oracle Linux 6ではext4、Oracle Linux 7 / 8ではxfsのファイルシステムを作成する。

Oracle Linux 7 / 8：

# mkfs.xfs /dev/vg01/lv_data
meta-data=/dev/vg01/lv_data      isize=256    agcount=4, agsize=3276544 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=13106176, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=6399, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Oracle Linux 6：

# mkfs.ext4 /dev/vg01/lv_data
mke2fs 1.43-WIP (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=256 blocks
3276800 inodes, 13106176 blocks
655308 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
400 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

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

ext4では、デフォルトで5%のリザーブ領域を確保する。データ領域にリザーブ領域は不要なのでゼロに変更する。心配性ならば1で。xfsには同じ仕組みが無いので実行しない。

# tune2fs -m0 /dev/vg01/lv_data
tune2fs 1.43-WIP (20-Jun-2013)
Setting reserved blocks percentage to 0% (0 blocks)

ここまででブロックボリューム側の準備ができた。次に作成したブロックボリュームをマウントする。

5-7. ブロックボリュームをマウントする

残りの作業はあとわずかだ。マウントポイントを作成して、マウントするだけである。ただし、UUIDもしくはコンシステンス・デバイス・パスのどちらかで/etc/fstabの記述が異なる。利用環境に応じて設定すること。

5-7-1. マウントポイントを作成する

マウントポイント用のディレクトリを作成し、オーナーをopcに変更する。各自の環境に読み替えて適宜変更して欲しい。

# mkdir /mnt/vol01
# chown opc:opc /mnt/vol01

5-7-2. UUID用の/etc/fstabを作成する

UUIDでデバイス名を指定するので、lsblkで該当デバイスのUUIDを調べる。

# lsblk -o +UUID
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT UUID
sdb      8:16   0   50G  0 disk
└─sdb1   8:17   0   50G  0 part            Lobmfv-K3tR-2lzz-Zizs-eQx4-iF8E-9nmeca
  └─vg01-lv_data
       252:0    0   50G  0 lvm             f451d63f-1692-44ea-ad37-82ffa3313226 ★これがlv_dataのUUID
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]     8c83c999-ef07-40b5-b001-9658556502d3
├─sda3   8:3    0 38.4G  0 part /          eb7fd29b-a114-4e5e-8926-a6f4a541d605
└─sda1   8:1    0  200M  0 part /boot/efi  52AE-1880

UUIDはlsblkで確認するが、次のように逆引きもできる。

# findfs UUID=f451d63f-1692-44ea-ad37-82ffa3313226
/dev/mapper/vg01-lv_data

以下のように/etc/fstabを作成する。

# vi /etc/fstab
★末尾に以下の行を追加する
UUID=f451d63f-1692-44ea-ad37-82ffa3313226  /mnt/vol01 xfs defaults,_netdev,nofail 0 2

それぞれの意味は次の通り。 1番目：デバイス名 2番目：マウントポイント 3番目：ファイルシステムのタイプ 4番目：ファイルシステムのマウントオプション 5番目：dumpコマンド実行時に対象にするか。対象にするときは1 6番目：fsckの実行順序。ルートファイルシステムは1。それ以外は2。対象外にするときは0

この中でもっとも重要なのが「_netdev」と「nofail」である。_netdevはネットワーク系のサービスが起動してからマウントするオプションで、リモートストレージでは必須。またnofailはディスク障害などでマウントできないときは、マウントをスキップして起動するオプションである。

「nofail」を指定しないとリモートディスク障害時にOSが起動できなくなる。また/etc/fstabに追加エントリがあるカスタムイメージを作成すると、そのカスタムイメージを使ってComputeインスタンスを作成してもOSが起動できない。

5-7-3. コンシステンス・デバイス・パス用の/etc/fstabを作成する

LVMを使用しないときは、コンシステンス・デバイス・パスとUUIDのどちらも使用できる。コンシステンス・デバイス・パスを使用するときは以下のように/etc/fstabを作成する。

# vi /etc/fstab
★末尾に以下の行を追加する
/dev/oracleoci/oraclevdb1 /mnt/vol01 xfs defaults,_netdev,nofail 0 2

5-8. ファルシステムをマウントする

ファイルシステムをマウントすると/mnt/vol01に約50GBのブロックボリュームが追加されていることがわかる。

# mount -a
# df -h
Filesystem                Size  Used Avail Use% Mounted on
devtmpfs                  7.2G     0  7.2G   0% /dev
tmpfs                     7.3G     0  7.3G   0% /dev/shm
tmpfs                     7.3G  8.6M  7.3G   1% /run
tmpfs                     7.3G     0  7.3G   0% /sys/fs/cgroup
/dev/sda3                  39G  2.1G   37G   6% /
/dev/sda1                 200M  9.7M  191M   5% /boot/efi
tmpfs                     1.5G     0  1.5G   0% /run/user/1000
/dev/mapper/vg01-lv_data   50G   33M   50G   1% /mnt/vol01　★この行が追加

6. おわりに

「partedやLVMを使おうぜ」って、つもりで書き始めたのだが、新機能のコンシステンス・デバイス・パスに少し苦戦。従来通りUUIDを使用することにした。またLVMを利用するとレイヤが増えるのでパフォーマンスが低下するという人もいるが、微々たるものだろう。結局のところ利便性とのトレードオフだ。

今回はデータ領域用に新しくブロックボリュームを追加したが、既存のボリュームを拡張する方法もある。これはオンプレミスのベアメタルサーバでは難しい芸当だろう。

  • ブートボリュームを拡張
  • 既存のブロックボリュームを拡張

拡張時の操作はLVMよりも複雑になるが、LVMを使いたくないユーザにとっては便利な選択肢になる。詳しくは以下のマニュアルやエントリを参照のこと。賢いLinuxライフを！

7. まとめ

  • ディスクサイズを増やす方法には、ブロックボリュームを追加する方法と、既存のボリュームを拡張する方法がある
  • partedを使うと、gptパーティションや非対話的にパーティションを作成できる
  • マウントオプションに「_netdev」と「nofail」は絶対指定する
  • ブロックストレージを追加するとデバイス名が変わる可能性があるので、コンシステンス・デバイス・パスかUUIDを使用するべし
  • コンシステンス・デバイス・パスは便利な機能だがLVMでは使えない（使う方法があるってかたがいたら教えて）

8. コピペ用まとめバージョン

コピペ用の手順は以下の通り。7/8系OSでの利用を想定しているが、6系OSでも実行可能。ext4がいいときには変更すること。最後の/etc/fstabへの追加はシェルスクリプトにすれば可能だが、コピペでだけで実現したかったので元ネタを提供。

LVMを使わないときのサンプルコピペはコチラのリンク先を参照のこと。

# パーティション作成
parted -s -a optimal /dev/sdb mklabel gpt mkpart primary 0% 100% set 1 lvm on

# LVM設定
pvcreate /dev/sdb1
vgcreate vg01 /dev/sdb1
lvcreate -l 100%FREE -n lv_data vg01

# ファイルシステム作成
mkfs.xfs /dev/vg01/lv_data

# マウントポイント作成
mkdir /mnt/vol01
chown opc:opc /mnt/vol01

# /etc/fstab元ネタ。次の3行をマージして末尾に追加する
echo UUID= ; lsblk -o +UUID | grep vg01-lv_data | awk '{print $NF}' ; echo "    /mnt/vol01 xfs defaults,_netdev,nofail 0 2"

Oracle LinuxのデフォルトカーネルをスマートにUEKからRHCKに変更する

Linux Oracle Linux

前提条件

※UEKがデフォルトインストールされているのはOracle Linux 8 Update 2以降

はじめに

Oracle Linuxには2種類のカーネルがある。1つはデフォルトカーネルのUEK（Unbreakable Enterprise Kernel）で、もう1つはRed Hatと完全に互換性を持つRHCK（Red Hat Compatible Kernel）である。UEKにはR4、R5など、さらにいくつかあるのだが、本題では無いので無視する。

今回何が言いたいかというと、

UEK→RHCKの変更に関する情報はたくさん転がっているけれど、スマートではないものが多いんじゃね？

7系になってGRUB2に変更されたことが大きく影響しているのだけれど、独断と偏見で、スマートな変更方法について語りたい。

UEKとRHCKの互換性

UEKとRHCKではベースカーネルのバージョンは違うが、ユーザー空間で動作するアプリケーションについてはABI（Application Binary Interface）互換性がある。そのため一般的なアプリケーションの動作では、ほとんど影響しない。

なぜRHCKか？

UEKとRHCKでは互換性かあるのは知っているけれど、RHCKを使いたいケースがある。

たとえば、使う商用パッケージがサポートするのはRHCKだけとか、RHCKのほうが利用者が多いので安定してるんじゃね（全RHEL系ディストリビューション含む）といった理由だ。

次に実際の方法を解説する。

環境を確認する

これからOracle Linux 7 / 8における変更方法を説明する。6系は違うので注意すること。

ディストリビューション＆バージョンを調べる。

# cat /etc/oracle-release
Oracle Linux Server release 7.6

現在のカーネルを確認すると、UEKカーネルになっていることがわかる。

# uname -r
4.14.35-1844.3.2.el7uek.x86_64

インストールされているカーネルを確認すると、UEKとRHCKがインストールされている。

# rpm -qa | grep kernel | sort
abrt-addon-kerneloops-2.1.11-52.0.1.el7.x86_64
kernel-3.10.0-957.10.1.el7.x86_64
kernel-3.10.0-957.12.1.el7.x86_64 ★これにしたい
kernel-3.10.0-957.5.1.el7.x86_64
kernel-tools-3.10.0-957.12.1.el7.x86_64
kernel-tools-libs-3.10.0-957.12.1.el7.x86_64
kernel-uek-4.14.35-1844.2.5.el7uek.x86_64
kernel-uek-4.14.35-1844.3.2.el7uek.x86_64 ★これが現在
kernel-uek-4.14.35-1844.4.5.el7uek.x86_64

見落としがちなのが/etc/sysconfig/kernelで、yum updateするときは、このファイルが参照される。アップデートパッケージがあるときには、こちらで指定した方がでデフォルトカーネルになる。

# cat /etc/sysconfig/kernel
--ここから下がファイルの中身--
# UPDATEDEFAULT specifies if new-kernel-pkg should make
# new kernels the default
UPDATEDEFAULT=yes

# DEFAULTKERNEL specifies the default kernel package type
DEFAULTKERNEL=kernel-uek

grubbyを使って変更する

GRUB2で便利なのがgrubbyである。これを使うとかなりスマートに変更できる。詳しくはgrubby --helpや下記のマニュアルを見て欲しい。

参考：grubby ツールを使用した GRUB 2 メニューの永続的な変更

デフォルトのカーネルを表示する。

# grubby --default-kernel
/boot/vmlinuz-4.14.35-1844.4.5.el7uek.x86_64

デフォルトのインデックス番号を表示する。これだけではよく分からないので、次にメニューを全表示する。

# grubby --default-index
0

メニューを全部表示するには--info=ALLを指定する。

# grubby --info=ALL
index=0　★現在はインデックス番号0のこれ↓
kernel=/boot/vmlinuz-4.14.35-1844.4.5.el7uek.x86_64
args="ro crashkernel=auto LANG=ja_JP.utf8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 network-config=e2NvbmZpZzogZGlzYWJsZWR9Cg== loglevel=4"
root=UUID=0efcd14b-2edf-4b85-ae64-4c3855ca5a58
initrd=/boot/initramfs-4.14.35-1844.4.5.el7uek.x86_64.img
title=Oracle Linux Server 7.6, with Unbreakable Enterprise Kernel 4.14.35-1844.4.5.el7uek.x86_64
index=1
kernel=/boot/vmlinuz-3.10.0-957.12.1.el7.x86_64 ★これに変更したい
args="ro crashkernel=auto LANG=ja_JP.utf8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 network-config=e2NvbmZpZzogZGlzYWJsZWR9Cg== loglevel=4"
root=UUID=0efcd14b-2edf-4b85-ae64-4c3855ca5a58
initrd=/boot/initramfs-3.10.0-957.12.1.el7.x86_64.img
title=Oracle Linux Server 7.6, with Linux 3.10.0-957.12.1.el7.x86_64
index=2
kernel=/boot/vmlinuz-0-rescue-9c95796465364eaf81b3c9f027d03ee6
args="ro crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 network-config=e2NvbmZpZzogZGlzYWJsZWR9Cg== loglevel=4"
root=UUID=0efcd14b-2edf-4b85-ae64-4c3855ca5a58
initrd=/boot/initramfs-0-rescue-9c95796465364eaf81b3c9f027d03ee6.img
title=Oracle Linux Server 7.6 Rescue 9c95796465364eaf81b3c9f027d03ee6 (3.10.0-957.10.1.el7.x86_64)
★中略
index=8
non linux entry

デフォルトカーネルをRHCKに変更する。--set-default-index=<index number>を使えばインデックス番号を使えるが、間違いの元なので使わない。

# grubby --set-default /boot/vmlinuz-3.10.0-957.12.1.el7.x86_64

変更されていることを確認する。

# grubby --default-index
1
# grubby --default-kernel
/boot/vmlinuz-3.10.0-957.12.1.el7.x86_64

最後に/etc/sysconfig/kernelでデフォルトカーネルをRHCK変更する。これを変更しないとyum updateしたときにUEKに戻ってしまう。

# vi /etc/sysconfig/kernel

変更前： 　DEFAULTKERNEL=kernel-uek

変更後： 　DEFAULTKERNEL=kernel 　#DEFAULTKERNEL=kernel-uek

ここまで終わればリブートする。

# reboot

再起動したら確認する。次のようにRHCKに変わっていることがわかる。

# grubby --default-kernel
/boot/vmlinuz-3.10.0-957.12.1.el7.x86_64
# grubby --default-index
1

おわりに

一通りの手順を見てどうだろうか。grub2-mkconfigなどのgrub2系コマンドもあるが、それよりもずいぶんスマートにできたはずである。

参考資料