RHEL 6 から 7 で何が変わるか
会社の自席 PC の OS を CentOS 6 から 7 にアップグレードするのに先駆けて、アップグレード方法や変更点について調べた。 本エントリでは、主に変更点についてまとめているが、アップグレード方法に関しては、付録として末尾に記載している。
ブートローダが GRUB2 になった
GRUB2 は、より多くのファイルシステム、仮想ブロックデバイスをサポートする。 一方、MBR 形式のパーティションテーブルを持つ BIOS マシンでフォーマットされたパーティションに、ブートローダをインストールすることができなくなった。
init システムが systemd になった
init システムが SysVinit から systemd に移行された。 SysVinit との互換性は残されているが、多くのそれは非推奨とされている。
関連するところで、chkconfig コマンドも非推奨とされている。 systemd は、ターゲットと呼ばれる機能により同等の機能を提供している。
SysVinit との後方互換機能
/etc/init.d/ 以下のスクリプトを直接叩くことは非推奨で、service コマンドや、service コマンドと同等の機能を内包する sysctl コマンドの利用が推奨される。 また、ランレベルの使用は非推奨で、systemd ターゲットと呼ばれる同等の機能の利用が推奨される。
systemd によってもたらされる新機能
systemd は、プログラムの並列実行により、高速なブートプロセスを提供する。 systemd では、init スクリプトの実行を 5 分間でタイムアウトすることで、不正な init スクリプトの存在によるブートプロセスの阻害を回避している。 systemd では、稼働していないサービスの停止処理は実行しない。
システムのファイルレイアウトが変わった
/bin, /sbin, /lib, /lib64 が /usr 以下に移動した。 これは、/usr ファイルシステムのマウント方法の改善により、/ 以下に配置する必要がなくなったためである。 代わりに、互換性のためのシンボリックリンクが同等のパスに貼られている。
また、/tmp, /run に tmpfs ファイルシステムを割り当てられるようになった。 tmpfs ファイルシステムを割り当てた場合には、これらのディレクトリに永続化の必要なファイルを置いてはいけない。
ロギングフレームワーク journald が追加された
6 に引き続き rsyslogd が提供されるが、これと共存する形で journald も提供される。 rsyslogd との共存は、journald が受け取った syslog メッセージを、rsyslogd に転送することにより実現されている。
journald は、受け取ったログ、メモリ、もしくは /run/log/journal 以下に格納する。 journald はその特徴として、ログをインデックス化したジャーナルファイルとして保存することで、ログの高速検索に対応している。 一方、ジャーナルファイルはバイナリファイル形式なので、閲覧には journal コマンドを利用する必要がある。 また、リソースが不足した場合には、一番古いジャーナルファイルを消すことで、ログを継続する。
yum, rpm がバージョンアップされた
yum のバージョンアップにより、group サブコマンド、yum-security, yum-presto の統合、パッケージの並列ダウンロードに対応した。 また、rpm のバージョンアップにより、競合検出の厳格化、単一パッケージの複数バージョンの同時インストールに対応した。
ifconfig コマンドが非推奨になった
ifconfig コマンドは廃止予定となり、その使用は非推奨となった。 これに伴って /etc/ifconfigs 以下の設定ファイルのフォーマットが更新されている。 また、ip ユーティリティとそのサブコマンド addr, link の使用が推奨されている。
ファイルシステムのデフォルトが XFS になった
RHEL 6 ではデフォルトで Ext4 が使われていたが 7 からは XFS に変更された。 XFS は、より巨大なサイズ割り当てと、メタジャーナリングシステムに対応するファイルシステムである。
Btrfs が提供されるようになった
新しいファイルシステムとして Btrfs が提供された。 またテクノロジープレビューとしての提供で、安定性を求めるのであれば XFS や Ext4 を選択すべきである。
LVM 機能が強化された
RHEL 7 から LVM キャッシュボリュームに完全対応した。 これは、小規模で高速なデバイスを大規模で低速なデバイスのキャッシュとして動作させることのできる仕組みである。
さらに、LVM シンプロビジョニングがサポートされた。 これは、ストレージサイズの仮想化を実現する機能で、物理的な値よりも大きいストレージサイズを与えることができる。
デスクトップ環境が更新された
デスクトップ環境は GNOME 3 と KDE 4.10 をサポートする。
デフォルトのデスクトップ環境として提供されるのは GNOME Classic で、 これは GNOME 2 のルックアンドフィールを維持する、GNOME 3 の拡張セットである。
クラスタリングツールが更新された
RHEL 6 ではクラスタ制御ツールとして luci が提供されていたが、RHEL 7 ではこれが削除されて pcs に置き換えられた。 また、ロードバランサとして提供されていた Piranha が削除されて、Keepalived に置き換えられた。 また、リソースマネージャとして提供されていた rgmanager と cman が削除さて、Pacemaker と Corosync に置き換えられた。
動的ファイアウォール firewalld が追加された
RHEL 6 に引き続き iptables がファイアウォールを提供するが、これをラップするツールとして firewalld が追加される。
firewalld の肝としてはその設定更新が動的であること。 iptables と違って、ルーティング設定更新時に一度設定がクリアされることがないため、ネットワークが止める必要がない。
ちなみに、設定ファイルも iptables とは別で管理される。 firewalld を無効化にしてもよいので、煩わしければそうしてもいい。
付録： アップグレード方法
クリーンアップグレードか、インプレースアップグレードか
クリーンアップグレードは、基本的に全てのシステムデータを消してアップグレードする方法。（再インストールと一緒じゃないのか？） インプレースアップグレードは、既存のシステムを維持しつつ、いい感じにアップグレードする方法。
RHEL は 7 において、初めてインプレースアップグレードに対応した。 そういったこともあってかいくつか制限があって、例えば、CentOS の最新バージョンは 6.9 だけど、6.7 以前からのアップグレードにしか対応していない。 これは、6.8 から一部のシステムパッケージで、7 で使われているものより上のバージョンが使われているためである。
https://access.redhat.com/ja/node/1338443 https://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
大まかなインプレースアップグレード手順
yum updateで OS のマイナーバージョンと全パッケージを最新に更新- アップグレード用のパッケージダウンロードのための yum リポジトリを追加
- アップグレード用のパッケージをダウンロード
- アップグレードが可能であるかマシンを検査するためのツール
preupgを実行- Binary rebuilds で心が折れそうになるが、全体通して2時間半程度で終わるのでひたすら待つ
- アップグレードツール
redhat-upgrade-toolを実行
https://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/chap-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Upgrading.html#chap-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Upgrading_from_RHEL6
