Qiitaに記事を書きました。
Switchbot Meterから温度・湿度を取得して、Muninで可視化するメモ - Qiita
CentOS 8 を Oracle Linux 8 に切り替える
概要
CentOS 8 を Oracle Linux 8 に切り替える方法について記載します。
背景
CentOS 8 の開発が終了し、CentOS Stream に統一されるとの発表がありました。CentOS Stream はRHELのプレリリース版のような位置づけで、特定のバージョンはなくローリングリリース方式となります。RHELの代わりに使えるケースもあると思いますが、特定のRHELのバージョンと合わせた環境がほしいような場合は要件に合わないこともあると思います。
Oracle Linux とは？
Oracle Linux は、Oracleによって開発されている RHEL Clone のLinuxディストリビューションで、10年以上の歴史があり、今も開発が続いています。
Oracle Databaseを代表とする血も涙もないライセンスのOracle製品とは異なり、Oracle Linuxは以下のようなかなり柔軟なライセンス体系となっています。
- 無料で使用できる。本番環境でも使用できる。（RHELは開発版は無償だが本番では使えない）
- サポートが必要なら必要な分だけ購入できる。（RHELは全部購入しないといけない）
- RHELやCentOSからも移行してもサポートを受けられる。
- Ksplice などの Oracle Linux 独自の機能もある。（要Premier Support）
かつてはずいぶん叩かれましたが、当時から今まで柔軟なライセンス体系のまま開発が継続されていますので、CentOSが無くなるなら現実的な移行先として有力なのではないかと思います。
CentOS → Oracle Linux の移行手順
Oracle LinuxはRHELおよびCentOSからの移行方法を公開しています。CentOS 6 or 7 からの移行方法はこちらに公開されていますが、CentOS 8 はやり方が違うようです。
(2020/12/16追記) 移行ツールがCentOS8にも対応しました。このページの内容はさっそく不要になりました。
CentOS 8 から Oracle Linux 8 への移行方法はサポートが必要なところにドキュメントがあるようです。（公開した方がいいと思うなー）
サポートが必要な情報を使うのは微妙なので、こちらで言及されていた方法でやってみようと思います。やってる内容はほとんど変わらないと思いますが。
移行してみるテスト
VirtualBoxにCentOS 8 をインストールします。
起動時はもちろん CentOSです。
Oracle Linuxのリポジトリから必要なRPMをダウンロードします。
$ repobase=http://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage
$ wget \
${repobase}/redhat-release-8.3-1.0.0.1.el8.x86_64.rpm \
${repobase}/oraclelinux-release-8.3-1.0.4.el8.x86_64.rpm \
${repobase}/oraclelinux-release-el8-1.0-9.el8.x86_64.rpm
そのままだと依存関係でRPMが入らないので centos-linux-release を削除します。
# rpm -e --nodeps centos-linux-release
Oracle Linuxのリポジトリ関連のRPMをインストールします。
# rpm -ivh *.rpm
ociregionファイルを作っておきます。これはOCI（Oracle Cloud）ではリージョンに応じてリポジトリサーバを変えるための仕組みのようです。
# :> /etc/dnf/vars/ociregion
# dnf remove centos-linux-repos
これで、DNFのリポジトリはOracle Linuxのものになります。
# dnf repolist repo id repo name ol8_UEKR6 Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64) ol8_appstream Oracle Linux 8 Application Stream (x86_64) ol8_baseos_latest Oracle Linux 8 BaseOS Latest (x86_64)
パッケージをOracle Linuxのものに入れ替えます。CentOSとOracle Linuxのパッケージが混ざってもよければやらなくてもよいです。
# dnf --refresh distro-sync ... パッケージが入れ替わります
Oracle Linux 独自の Kernel（Unbreakable Enterprise Kernel）を使うこともできます。
# dnf install kernel-uek
EFI bootの場合は再起動する前に grub.cfg を作り直す手順も必要です。
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
ファイルがあることを確認します。
# ls -l /etc/grub2-efi.cfg lrwxrwxrwx. 1 root root 31 Nov 5 14:56 /etc/grub2-efi.cfg -> ../boot/efi/EFI/redhat/grub.cfg # ls -l /boot/efi/EFI/redhat/grub.cfg -rwx------. 1 root root 6544 Dec 11 04:51 /boot/efi/EFI/redhat/grub.cfg
再起動します。
# reboot
UEKで動作していることがわかります。
# uname -r 5.4.17-2036.100.6.1.el8uek.x86_64
/etc/oracle-release があります。
# cat /etc/oracle-release Oracle Linux Server release 8.3
Oracle Linuxでは、/etc/redhat-release には Red Hat と書かれてます。
# cat /etc/redhat-release Red Hat Enterprise Linux release 8.3 (Ootpa)
Kata Containers on Oracle Linux について Oracle Open World でお話ししてきました
概要
2019/9にサンフランシスコで開催されたOracle Open World 2019で登壇する機会をいただきました。Linuxとセキュリティという切り口で、Oracle LinuxのPMのSimon Coterさんといっしょに、Kata Containersというセキュリティ指向のコンテナランタイムについてお話ししてきました。
実は英語で登壇するのは初めての経験だったので、出落ちのクレイジージャパニーズくらいの気持ちで行きましたが、それなりに形になってたようです。我ながらかなりの変態ミッションだったと思います。
- 夏休みの個人旅行でOracle Open Worldに行く
- 個人で登壇する
- 英語で30分ぐらい話してデモもやる
- アイスブレイクでけん玉をちょっとやる
Oracle Open Worldに登壇した日本人はいっぱいいますが、けん玉をやった人はいないでしょう。
Oracle Open World 2019 の資料はこちらのサイトからダウンロードできます。（英語版です）
2019/8に日本で開催された、Oracle Modern Cloud Day Tokyoでも、同じ内容を日本語でお話しさせてもらったので、そちらの資料を使って解説したいと思います。
Oracle Modern Cloud Day Tokyo の資料はこちらのサイトからダウンロードできます。
https://www.oracle.co.jp/campaign/moderncloudday/2019/
導入
表紙の背景に特に意味はありませんが、自分で撮影してきた天体写真をぶっ込むスタイルでいきました。この写真は2017年8月にアメリカで撮影してきた皆既日食の写真です。OOWで皆既日食を見た人がいるか聞いてみたら、2,3人手を上げてくれました。
余談ですが、2017/8/21 北米皆既日食の記事はこちら。
自己紹介スライドはいつもながら自己主張強めです。OOWではちょっとけん玉やりました。だいぶうけてたのでアイスブレイクには成功したようです。芸は身を助ける、です。
アプリケーションコンテナ
コンテナ型仮想化の歴史は、1979年にUnixに実装されたchrootに遡ります。chrootはプロセスからファイルシステムを隔離する仕組みで、今でもよく使われます。2000年には、FreeBSDでJailという仕組みが導入されました。これはchrootをさらに強化したもので、プロセス空間も隔離します。Jailによって、OSの中に仮想OSを作るような使い方ができるようになりました。2005年には、Solaris 10でSolaris Zones (Solaris Containers)という仕組みが導入されました。これはほぼ仮想サーバのような機能で、ZonesがあるからSolarisを使っていた方も多いんじゃないかと思います。Solaris 11では、Kernelまで隔離した、Kernel Zonesというほぼハイパーバイザのような機能も導入されました。
またも余談ですが、2014年にSolarisのVPのBill Nesheimさんといっしょに、Solarisの仮想化についてお話ししたことがありました。我ながら、面白い機会をいただいていてありがたいことです。 www.sbbit.jp
Linuxでのコンテナ型仮想化も歴史が長く、2000年代半ば頃から、OpenVZ/Virtuozzoや、Linux-Vserverがレンタルサーバなどによく使われていました。初期のDockerでも使われていたLXCや、LXCを便利にした感じのLXDや、systemdに統合されたsystemd-nspawnなど、様々な実装があります。 2013年にDockerが登場してからアプリケーションコンテナが一気に広まってきました。2014年にKubernetesが登場し、今回紹介するKata Containersは2017年に登場したかなり新しい技術です。
今ではすっかり、「コンテナ」と言えば「アプリケーションコンテナ」のことを指すようになってしまいましたが、私は単に「コンテナ」と言うと、コンテナ型仮想化（OSレベル仮想化・システムコンテナ）の方を想像してしまうので、なるべく「アプリケーションコンテナ」と言うようにしていたりします。コンテナ型仮想化は、仮想サーバと同じような使い方をしますが、アプリケーションコンテナはその延長線上にはないのではないかと思います。
アプリケーションコンテナと従来のコンテナ型仮想化は似ていないと言いましたが、アプリケーションコンテナはサーバ仮想化などのインフラの話よりも、アプリケーション開発やDevOpsの文脈で語られることが多いのではないかと思います。Dockerの典型的な使い方としては、ビルド、パッケージング、デプロイという流れになると思いますが、昔からあるサーブレットコンテナととてもよく似ていたりします。アプリケーションコンテナとは、仮想サーバを置き換えるものではなく、アプリケーションをデリバリするためのものであると捉えるのがわかりやすいと思います。
アプリケーションコンテナのセキュリティ
ガートナーが最近出しているリサーチによると、2019年時点で、アプリケーションコンテナを商用で使っている組織は、ワールドワイドで30%未満とのことです。しかし、2022年にはこれが75%超になると予想されています。 会場の方に、アプリケーションコンテナを商用で使っているか聞いてみたところ、日本のModern Cloud Dayでは10%未満でしたが、アメリカのOpen Worldでは30～40%くらいの方が手を上げました。ガートナーのリサーチはそれなりに当たっていそうな感じです。 ガートナーは同じ記事の中で、アプリケーションコンテナを商用で使うための、6つの重要な要素を挙げていて、その1番目に「セキュリティ＆ガバナンス」を挙げています。
アプリケーションコンテナのセキュリティと一言に言っても、どうすればいいのかなかなか難しいです。NIST（米国国立標準技術研究所）がよくまとまった文書を公開しているので、そちらを参照してみましょう。NIST SP800シリーズはセキュリティ関連の文書で、SP800-190 はアプリケーションコンテナのセキュリティについてまとめられています。2017年9月に公開されたものなので、かなり新しい文書です。 その中で、アプリケーションコンテナの典型的なアーキテクチャは上の図のようなコンポーネントから成り立っていると述べられています。図の左から、開発者がコンテナイメージを作って、テストして、レジストリに登録して、管理者がオーケーストレータを使ってホストにデプロイする、という流れになっています。Docker、Kubernetes、DockerHubなどは、このアーキテクチャの実装例といえます。
SP800-190はこちらからダウンロードできます。 csrc.nist.gov
一部の文書はIPAが日本語化して公開しています。SP800-190はまだないようです。 www.ipa.go.jp
同文書の中で、アプリケーションコンテナには5つの主要なリスクがあると述べられています。5つのリスクとは、イメージのリスク、レジストリのリスク、オーケストレータのリスク、コンテナランタイムのリスク、ホストOSのリスクです。
コンテナイメージの中身は、概ね上のような図のようになっています。先ほど、アプリケーションコンテナはアプリケーションをデプロイするためのものだと述べました。誤解を恐れずに言えば、アプリケーションの開発者はほぼアプリケーションにしか興味がないことが多いんじゃないかと思います。でも、コンテナの中身はOSイメージそのものなので、インフラやセキュリティの人は、ライブラリやユーザランドが気になってしまうのではないかと思います。 でも一般に、アプリケーションコンテナの場合は、中に入ってプロセスを監視したりログを監視するようなことはあまりやりません。むしろお行儀が悪いと言われたりします。これは仮想サーバのように使うコンテナ型仮想化の場合とは異なるやり方が必要になりますが、セキュリティとしてはコンテナイメージの中身も見る必要があります。DevOpsにセキュリティを加えたDevSecOpsのような考え方が必要になるということだろうと思います。
次に、ホストOSのリスクの中の、Kernelの共有の項目に注目したいと思います。一般的に、アプリケーションコンテナ環境では、アプリケーションレベルで隔離が行われているものの、Kernelを共有しており、ハイパーバイザによる仮想化より隔離のレベルが低いと考えられます。Kernelを共有しているので、1つのアプリケーションコンテナが侵害されれば、ほかのアプリケーションコンテナもリスクにさらされる可能性が高いといえます。この手の攻撃が刺さる可能性はそう高くないかもしれませんが、カーネルを共有していることがセキュリティの論点になることはあるということです。
Kata Containers
Kernelの共有がセキュリティのリスクになることがあるということから、ようやくKata Containersの話に入ります。ハイパーバイザの技術を利用し、 アプリケーションの強い隔離を実現するコンテナランタイムで、OpenStack Foundataion（OSF）がサポートしています。2017/12に出たばかりのとても新しい技術です。 コンテナオーケストレータは、今のところKubernetesがデファクトスタンダードといえますが、一方、コンテナランタイムはいろいろな特性を持ったものが出てきています。Kata Containersはかなりセキュリティに振り切ったコンテナランタイムだと言えます。
この図は、Kata Containersのアーキテクチャを模式図にしたものです。一般的なコンテナランタイムでは、左の図のように、Kernelを共有して、Namespaceの機能でアプリケーションを隔離します。それに対して、Kata Containersでは、アプリケーションコンテナ毎にKernelが分離するので、ハイパーバイザによる仮想化と同等の隔離を実現しています。
この図は、DockerとKata Containersの関連性を表したものです。kata-runtimeはLow-Levelのコンテナランタイムです。また、CNCFが策定したOCI Runtime Specificationに準拠しています。Dockerでは、通常runCがLow-Levelコンテナランタイムとして使用されますが、もちろんrunCもOCI Runtime Specificationに準拠しています。つまり、runCをkata-runtimeに置き換えることが可能ということになります。Kata ContainersはDockerやKubernetesを置き換えるものではなく、組み合わせて使うものと考えるのがよいと思います。
Kata Containersは、Oracle Linuxでは Oracle Linux Cloud Native Environment (OLCNE) の一部として取り込まれています。とはいえ、OLCNEという製品があるわけでもなく、サービスがあるわけでもありません。Oracle Linuxには、クラウドでのアプリケーション開発や運用に必要な機能がバンドルされているという、コンセプトのようなものだと私は理解しています。
Demo
こんな感じの環境で簡単なデモを行いました。仮想化にはVMware Playerを使いましたが、Oracle LinuxのPMのSimonさんは、VirtualboxのPMでもあるので、できればVirtualboxを使いたいと思っていました。Kata ContainersはKVMを使うので、仮想環境で動かすには、Nested VMができる必要があります。Virtualbox 6.0でAMDのCPUではNested VMに対応しているのですが、IntelのCPUではまだ対応していませんでした。VMware PlayerではIntel CPUでもNested VMができました。Virtualbox 6.1では、Intel CPUでもNested VMに対応予定のようなので、期待したいと思います。 イベントでは機材トラブルがつきものなので、デモをやるのは度胸が必要です。幸い日本でもアメリカでもデモ環境はすんなり動いてくれてよかったです。
デモのシナリオです。Docker Hubから取得した、Nginxのイメージを、Docker+runC と Docker+kata-runtime でそれぞれ起動するというデモを行いました。docker run の --runtime オプションを指定するだけで、必要に応じてコンテナランタイムを切り替えることができ、混在させることもできます。 Solaris 11をよく知っている方は、Native ZonesとKernel Zonesとの関係に似ていると考えるとわかりやすいんじゃないかと思います。
Oracle LinuxでKata Containersを使うのはわりと簡単です。この手順は、Developer Previewでの手順なので、GA(General Availability)になったら変わるかもしれませんのでご了承ください。
# yum-config-manager --enable ol7_addons # yum-config-manager --enable ol7_developer # yum-config-manager --enable ol7_developer_kvm_utils
必要なRPMをインストールします。
# yum install docker-engine # yum install qemu # yum install oracle-olcne-release-el7 # yum install kata-runtime
Dockerの起動オプションを変更して、kata-runtimeを有効にします。
# vi /etc/sysconfig/docker --- OPTIONS='-D --add-runtime kata-runtime=/usr/bin/kata-runtime' # systemctl restart docker
Kata Containersを使用するには、KVMが有効になっている必要があります。
# lsmod … kvm 643072 1 kvm_intel
設定がうまくいっていれば、docker info でランタイムが追加されているのがわかります。
# docker info … Runtimes: kata-runtime runc
docker run でコンテナを起動すると、runCの場合は1秒くらいで起動しますが、kata-runtimeは仮想マシンを起動するので4～5秒くらいかかりました。パフォーマンスのテストは詳細にはやっていませんが、KVMで仮想化しているのと同じくらいのオーバーヘッドはあると考えられます。 pstreeでプロセスを見ると、runCのほうはNginxのプロセスが見えているのに対して、kata-runtimeのほうは、qemuのプロセスが見えて、たしかに仮想化されているのがわかります。Nginxのプロセスは仮想マシンの中なので、ホストOSからは見えなくなっています。
まとめ
というわけで、アプリケーションコンテナを商用環境で使うときにはそれ相応のセキュリティを考慮する必要があるということと、Kernelの共有はセキュリティリスクとして論点になりうるという話から、ハイパーバイザの技術でアプリケーションコンテナを隔離するKata Containersというコンテナランタイムについて紹介しました。今後、Kata Containersが主流になるかはまったくわかりませんが、コンテナランタイムは必要に応じて特性の違うものを使い分けるようなケースが増えてくるのではないかと考えています。
またも余談ですが、最後のスライドも自分で撮影してきた天体写真をぶっ込みました。2018年に、世界有数の美しい星空だと言われる、ニュージーランドのテカポ湖で撮影してきた天の川の写真です。 ニュージーランド旅行の記事はこちらから。 shakemid.hatenablog.com
Elasticsearch Cluster on Linux Container
概要
Linuxコンテナ（systemd-nspawn）を使って、複数ホストにまたがるElasticsearchクラスタを構築してみました。 私はコンテナ歴12年くらいですが、ほとんどSolarisコンテナ（Zones）ばかり使っていて、Linuxコンテナはどんなものかよくわかっていないので、おかしなことを言っていましたらご指摘ください。
背景
以下のような感じの要件で、基盤のアーキテクチャを考えていました。
- 50～100ノード規模のElasticsearchクラスタを作りたい
- オンプレ環境で
- 一度起動したら年単位で動き続ける
- 商用ライセンスはあまり使いたくないけど、人柱になって自力でなんとかする気概はあり
なんとなく以下のような実現方式を考えました。本音はSolaris Zonesを使いたくてたまりませんが今回はLinux縛りです。
| カテゴリ | 方式 | 評価（主観） |
|---|---|---|
| 物理系 | 物理サーバ50台 | × ラックが足りない。運用嫌だ。 |
| 物理サーバ＋マルチプロセス | △ 運用嫌だ。 | |
| ハイパーバイザ系 | VMware | △ ライセンス必要。オーバーヘッド嫌だ。 |
| KVM, Xen | △ オーバーヘッド嫌だ。 | |
| コンテナ系 | Docker | △ どうも合わない。k8s, Swarmとかは大がかりすぎ。 |
| OpenVZ | △ まだあるのだろうか？ | |
| LXD | ○？ 良さそう。使うならUbuntuが良さそうか。 | |
| systemd-nspawn | ○？ ほぼOS標準の機能！ |
Dockerは少し検証してみたのですが、動くには動くのでしょうが、ホストまたぎのネットワークを構成するのが面倒で、KVSを立ち上げて、VXLANでオーバーレイネットワークとかになるのでやる気がなくなりました。 そのためだけにKubernetesとかSwarmを使うのも大がかりすぎに思えました。
DockerをDisる気はなく、用途がマッチすれば良いと思いますが、仮想マシンのようなことがやりたいならまったく不向きで、無理矢理使っても悲惨な運用になるのが落ちという感じがします。 長年Solarisコンテナを使ってきたのもあって、なるべくシンプルでほぼOS標準の機能で動作するということから systemd-nspawn にたどり着き、検証してみようと思いました。
なお、クラウド前提なら、Amazon Elasticsearch Service を検討するのもいいと思います。
シナリオ
今回構築する環境は以下のようなイメージです。物理マシンがあれば使ってもいいですが、私はVirtualBox上に構築することにしました。
構築は以下のような流れで進めました。
- ホスト構築編
- コンテナ構築編
- コンテナイメージをインストールする
- コンテナを起動する
- Elasticsearchをインストールする
- コンテナをコピーする
構築
ホスト構築編
CentOS 7 をインストールする
OSはユーザが多いであろうCentOSにしました。バージョンは現時点で最新の7.6にしました。
インストールはできましたが、グラフィカルインストーラだとマウスでボタンをクリックできないことがある謎の事象に遭遇したので、テキストインストーラを使う方がいいような気がします。
今回はホスト間で通信できる必要があるので、VirtualBoxのネットワークの設定でブリッジアダプターを使うとよいと思います。また、プロミスキャスモードを許可する設定も必要です。
また、OSの領域とコンテナの領域を分けたいので、ストレージの設定画面でディスクイメージを1つ追加しました。
SELinuxは無効にしました。
$ sudo vi /etc/sysconfig/selinux ---- ... SELINUX=disabled ...
systemd-networkd をインストールする
今回はホスト間で通信できるようにネットワークブリッジを使うので、ネットワークの管理をsystemd-networkdで行うのがよいようです。以下のページを参考にしました。
以下のページも参考にしました。systemd関連のドキュメントはArch Linuxのものがわかりやすい感じがします。
systemd-networkd と systemd-resolved をインストールします。
$ sudo yum install systemd-networkd systemd-resolved
設定ファイルを作成します。内容は環境に合わせて適当に変えてください。Redhat標準の /etc/sysconfig/network-scripts/ 以下のファイルは使われなくなります。
/etc/systemd/network/br0.netdev ---- [NetDev] Name=br0 Kind=bridge
/etc/systemd/network/enp0s3.network ---- [Match] Name=enp0s3 [Network] Bridge=br0
/etc/systemd/network/br0.network ---- [Match] Name=br0 [Network] Address=192.168.0.10 Gateway=192.168.0.254 DNS=192.168.0.254
systemd-networkd と systemd-resolved を有効にします。
$ sudo systemctl disable network NetworkManager $ sudo systemctl enable systemd-networkd systemd-resolved $ sudo reboot
resolve.conf を入れ替えておきます。
$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
networkctl コマンドで、IPアドレスなどを確認することが出来ます。
$ networkctl status
● State: routable
Address: 192.168.0.10 on br0
Gateway: 192.168.0.254 (XXX) on br0
DNS: 192.168.0.254
ZFS をインストールする（任意）
ZFSは必須ではありませんが、コンテナの領域を管理するのに都合が良さそうなので使ってみたいと思います。 systemd-nspawn はBtrfsと連携する機能があるようなのですが、ここは慣れ親しんだZFSにします。
ZFSをCentOSで使用するには、カーネルモジュールを追加する必要があります。ZFS on Linux の公式の手順に従ってインストールします。
$ sudo yum install http://download.zfsonlinux.org/epel/zfs-release.el7_6.noarch.rpm
zfs-kmod のほうを有効にします。
$ sudo vi /etc/yum.repos.d/zfs.repo ---- [zfs] name=ZFS on Linux for EL 7 - dkms baseurl=http://download.zfsonlinux.org/epel/7/$basearch/ -enabled=1 +enabled=0 metadata_expire=7d gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux @@ -9,7 +9,7 @@ [zfs-kmod] name=ZFS on Linux for EL 7 - kmod baseurl=http://download.zfsonlinux.org/epel/7/kmod/$basearch/ -enabled=0 +enabled=1 metadata_expire=7d gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux
ZFS をインストールします。
$ sudo yum install zfs
ARCのサイズを制限しておきます。
$ sudo vi /etc/modprobe.d/zfs.conf ---- options zfs zfs_arc_max=1073741824
ストレージプールを作成します。ZFS on Linux では、ls -l /dev/disk/by-id で表示されるデバイスIDを使用することが推奨されているようです。
$ sudo zpool create tank ata-VBOX_HARDDISK_XXXXXX-XXXXXX
tank という名前でストレージプールができました。
$ zpool list NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 39.8G 291K 39.7G - 0% 0% 1.00x ONLINE -
コンテナ用の領域（データセット）を作成します。compressionの設定はお好みに合わせてという感じです。近年はCPUが高速なので、圧縮した方が Disk I/O が減って高速になるケースもあります。
$ sudo zfs create -o compression=lz4 -o mountpoint=/var/lib/machines tank/machines $ sudo zfs create tank/machines/es11 $ sudo zfs create tank/machines/es12
こんな感じでデータセットができました。
$ zfs list NAME USED AVAIL REFER MOUNTPOINT tank 162K 38.5G 25.5K /tank tank/machines 73K 38.5G 25K /var/lib/machines tank/machines/es11 24K 38.5G 24K /var/lib/machines/es11 tank/machines/es12 24K 38.5G 24K /var/lib/machines/es12
systemd-nspawnでは、 /var/lib/machines/ 配下のディレクトリ名がコンテナのhostnameになるように想定されているようです。長さの制限は一見ないように見えるのですが、systemd-networkd がインタフェース名を自動生成するときに先頭11文字で切り落としてしまうようで、先頭11文字がユニークでないと名前が衝突するようです。そのうち改善するのかもしれませんが、ディレクトリ名（コンテナ名）は11文字以下にするのが無難なようです。
コンテナ構築編
コンテナイメージをインストールする
systemd-nspawn では、コンテナイメージをインストールする方法は主に3種類くらいあるようです。
- yum install --installroot でインストールする。chroot環境を作るのと似た感じ。
- ビルド済みのイメージを使う。Dockerのイメージも使えるようだ。
- すでに作成済みのコンテナからコピーする。
ひとまずオーソドックスな1.でやってみることにします。3.はあとからやります。
ZFSで作成した領域に最低限のパッケージをインストールします。
$ sudo yum -y --nogpg --releasever=7 --installroot=/var/lib/machines/es11 install systemd systemd-networkd passwd yum vim-minimal
lsで見ると、OSのイメージぽく見えます。
$ ls -l /var/lib/machines/es11/ total 17 lrwxrwxrwx. 1 root root 7 Apr 6 23:24 bin -> usr/bin dr-xr-xr-x. 2 root root 2 Apr 11 2018 boot drwxr-xr-x. 2 root root 3 Apr 6 23:24 dev drwxr-xr-x. 47 root root 113 Apr 6 23:25 etc drwxr-xr-x. 2 root root 2 Apr 11 2018 home lrwxrwxrwx. 1 root root 7 Apr 6 23:24 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Apr 6 23:24 lib64 -> usr/lib64 drwxr-xr-x. 2 root root 2 Apr 11 2018 media drwxr-xr-x. 2 root root 2 Apr 11 2018 mnt drwxr-xr-x. 2 root root 2 Apr 11 2018 opt dr-xr-xr-x. 2 root root 2 Apr 11 2018 proc dr-xr-x---. 2 root root 2 Apr 11 2018 root drwxr-xr-x. 12 root root 12 Apr 6 23:25 run lrwxrwxrwx. 1 root root 8 Apr 6 23:24 sbin -> usr/sbin drwxr-xr-x. 2 root root 2 Apr 11 2018 srv dr-xr-xr-x. 2 root root 2 Apr 11 2018 sys drwxrwxrwt. 7 root root 7 Apr 6 23:25 tmp drwxr-xr-x. 13 root root 14 Apr 6 23:24 usr drwxr-xr-x. 18 root root 21 Apr 6 23:24 var
ちなみに、圧縮率を見てみると2倍以上になっていてなかなかいい感じです。lz4は圧縮率と速度のバランスが良く、ZFSを使うならおすすめです。
$ zfs get compressratio tank/machines/es11 NAME PROPERTY VALUE SOURCE tank/machines/es11 compressratio 2.03x -
コンテナを起動する
systemd-nspawn -Dオプションで、イメージをインストールしたディレクトリを指定してコンテナを起動し、rootのパスワードを設定します。
$ sudo systemd-nspawn -D /var/lib/machines/es11 -bash-4.2# passwd ... -bash-4.2# exit
SELinuxを適切に設定するか無効にしないとパスワード変更で↓のようなエラーになるようなのでご注意ください。私は恥ずかしながらSELinuxをまともに使ったことがありません。
passwd: Authentication token manipulation error
コンテナをデーモンモードで起動します。
$ sudo systemd-nspawn -b -D /var/lib/machines/es11
起動シーケンスが走って、ログインプロンプトが出てくるのでrootでログインします。
Spawning container es11 on /var/lib/machines/es11. Press ^] three times within 1s to kill container. systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization systemd-nspawn. Detected architecture x86-64. Welcome to CentOS Linux 7 (Core)! ... CentOS Linux 7 (Core) Kernel 3.10.0-957.el7.x86_64 on an x86_64 es11 login: root Password: Last login: Sat Apr 6 23:43:37 on console
ps -ef で見ると、最低限のプロセスが起動しているのがわかります。
container# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 1 23:45 ? 00:00:00 /usr/lib/systemd/systemd root 14 1 0 23:45 ? 00:00:00 /usr/lib/systemd/systemd-journald dbus 19 1 0 23:45 ? 00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfil root 21 1 0 23:45 ? 00:00:00 /usr/lib/systemd/systemd-logind root 23 1 0 23:45 ? 00:00:00 login -- root root 25 23 0 23:45 console 00:00:00 -bash root 37 25 0 23:45 console 00:00:00 ps -ef
デフォルトでは、ホストとネットワークを共有しています。
container# networkctl status
● State: n/a
Address: 192.168.0.10 on br0
Gateway: 192.168.0.254 (JStream Technologies Inc.) on br0
Ctrl+] を3回入力するとコンテナが終了します。
Container es11 terminated by signal KILL.
ネットワークの設定を追加します。コンテナの中身はただのディレクトリなので、ホスト側からも見えます。
$ cd /var/lib/machines/es11 $ cd etc/systemd $ sudo mkdir network $ cd network
systemd-nspawnではhost0という仮想NICが自動的に作られるので、以下のように設定ファイルを作成します。
$ sudo vi host0.network ---- [Match] Name=host0 [Network] Address=192.168.0.11/24 Gateway=192.168.0.254 DNS=192.168.0.254
今度は、--network-bridge オプションを追加して起動します。
$ sudo systemd-nspawn -b -D /var/lib/machines/es11 --network-bridge=br0
host0にIPアドレスが設定されていることがわかります。これで、コンテナに独自のIPアドレスを割り当てて外部と通信できるようになりました。
container# networkctl status
● State: routable
Address: 192.168.0.11 on host0
Gateway: 192.168.0.254 on host0
DNS: 192.168.0.254
machinectl login でrootでログインできるように、/etc/securettyにpts/0を追記しておきます。
container# echo pts/0 >> /etc/securetty
いったん Ctrl+] を3回入力してコンテナを終了します。
Container es11 terminated by signal KILL.
ここからは、machinectlコマンドでコンテナを操作します。
ネットワークブリッジを使うように起動オプションを書き換えます。また、network.targetより後に起動するようにします。
$ sudo vi /usr/lib/systemd/system/systemd-nspawn\@.service > After=network.target ... < ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth --machine=%I --- > ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-bridge=br0 --machine=%I
machines.targetを有効にします。
$ sudo systemctl enable machines.target
machinectl enable でコンテナが自動起動するようにします。
$ sudo machinectl enable es11 Created symlink from /etc/systemd/system/machines.target.wants/systemd-nspawn@es11.service to /usr/lib/systemd/system/systemd-nspawn@.service.
machinectl start コマンドで、コンテナを起動できます。
$ sudo machinectl start es11
machinectl login コマンドで、コンテナにログインできます。
$ sudo machinectl login es11
ここまでで、コンテナを仮想サーバと同じような感覚で扱えるようになりました。
systemd-nspawn の概要は、例によって Arch Linux のページがわかりやすいと思います。
Elasticsearchをインストールする
ホスト側で、vm.max_map_countの値を増やしておきます。
$ sudo vi /etc/sysctl.d/10-vm.conf --- vm.max_map_count=262144 $ sudo sysctl -p
container# cd /etc/yum.repos.d container# vi elasticsearch.repo --- [elasticsearch-6.x] name=Elasticsearch repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md
Javaをインストールします。
container# yum install java-11-openjdk
Elasticsearchをインストールします。
container# yum install elasticsearch
設定を変更します。
container# cd /etc/elasticsearch
container# vi elasticsearch.yml
---
...
node.name: ${HOSTNAME}
network.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["192.168.0.11", "192.168.0.12","192.168.0.21", "192.168.0.22"]
本番で使うなら Shard allocation awareness も考慮した方がよいと思います。
サービスを有効にします。
container# systemctl daemon-reload container# systemctl enable elasticsearch.service container# systemctl start elasticsearch.service
動作確認してみます。ひとまず単一ノードで無事に起動しているようです。
container# curl http://localhost:9200/
{
"name" : "es11",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "Rnvu_GRyQoapvhnodWHb4A",
"version" : {
"number" : "6.7.1",
"build_flavor" : "default",
"build_type" : "rpm",
"build_hash" : "2f32220",
"build_date" : "2019-04-02T15:59:27.961366Z",
"build_snapshot" : false,
"lucene_version" : "7.7.0",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
コンテナをコピーする
いったんコンテナを停止します。
$ sudo machinectl poweroff es11
machinectlコマンドには、export-tarというオプションがあるようなのですが、CentOS 7 に付属のものはバージョンが古いのかそのオプションがありません。
machinectl(1) — Arch manual pages
仕方がないので、rsyncでコピーすることにします。
$ cd /var/lib/machines/ $ sudo rsync -av es11/ es12 ...
Node IDが重複しないように消しておきます。
container# rm -rf /var/lib/elasticsearch/nodes/0/
ネットワークの設定を書き換えます。
$ cd es12 $ cd etc/systemd/network $ sudo vi host0.network ---- [Match] Name=host0 [Network] Address=192.168.0.12/24 Gateway=192.168.0.254 DNS=192.168.0.254
machinectl enable でコンテナが自動起動するようにします。
$ sudo machinectl enable es12 Created symlink from /etc/systemd/system/machines.target.wants/systemd-nspawn@es12.service to /usr/lib/systemd/system/systemd-nspawn@.service.
machinectl start コマンドで、コンテナを起動します。
$ sudo machinectl start es11 $ sudo machinectl start es12
2台でクラスタ構成を組めていることを確認できました。
$ curl http://192.168.0.11:9200/_cat/health?v epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 1554574589 18:16:29 elasticsearch green 2 2 0 0 0 0 0 0 - 100.0%
ホストの追加
もう一式ホストを追加します。私はVirtualBoxのクローン機能を使って作りました。以下のあたりに気をつければ良いと思います。
- ホスト
- コンテナ
クラスタの状態を確認すると、無事に4台でクラスタ構成を組めていることを確認できました。
$ curl http://192.168.0.11:9200/_cat/health?v epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 1554575745 18:35:45 elasticsearch green 4 4 0 0 0 0 0 0 - 100.0%
まとめ
Linuxコンテナ（systemd-nspawn）でホストまたぎのElasticsearchクラスタを構築してみました。 Docker+Kubernetes よりはるかにシンプルにできたと思います。 今回は私の趣味で ZFS on Linux を使っていますが、ほぼOS標準の機能だけでもできるので、運用の観点でも安心感があるのではないでしょうか。
今回の検証で、Linuxコンテナを完全に理解しました（※チュートリアルを終えたレベルという意味）。なお、Solarisコンテナについては何もわかりません（※10年以上キャリアグレードの商用環境で使いまくったという意味）。
Qiitaにも上げてみました。 qiita.com
Solaris 11.4 on SuperMicro X10SDV-4C-TLN4F
背景
SuperMicroの X10SDV-4C-TLN4F で Solaris 11.4 が動作したのでメモしておきます。
私の家の自宅サーバはかれこれ14年ほどSolarisです。主な用途はNASなので、NAS専用機にしてもいいのですが、ZFSのpoolを脈々とスケールアップしてきたので（ZFSなら簡単）、わざわざ移行するのが面倒なのと、そもそもSolarisを使うこと自体が目的化しているので、敢えて他のOSに乗り換える理由が見当たりません。
最初に自宅サーバをSolarisにしたのは2005年なので、Solaris 10 が出てすぐくらいのときですね。 shakemid.hatenablog.com
2008年にAtomプロセッサが出たときにSolarisを動かしてました。 shakemid.hatenablog.com
2009年からOpenSolarisを使ってました。なつかしす。 shakemid.hatenablog.com
2012年に自宅サーバをXeonにしていました。このときは VMware ESXi 上で Solaris 11 を動かしてましたが、その後、ベアメタルにしていました。 shakemid.hatenablog.com
Solarisは2018年に出た11.4が現時点の最新バージョンで、今も進化しています。しかも、少なくとも2034年までサポートが継続されることが決まっており、安心して使えるOSだといえます。 https://blogs.oracle.com/solaris/oracle-solaris-114-released-for-general-availabilityblogs.oracle.com
SolarisはOracle DBなどと同じOTNライセンスの元、個人用途や開発用途では無償で使用できます。現実的に、自宅で使える商用UNIXはSolarisだけじゃないでしょうか。 www.oracle.com
マザーボード選定の経緯
要件は↓のような感じです。
この条件だと選択肢はほぼ SuperMicro しか残りません。昔から、Solarisが動くハードウェアを探すのはLinuxより難しいですが、SuperMicro の X10SDV シリーズはSolarisで動作確認が行われているというアドバンテージがあります。今回の目当ての X10SDV-4C-TLN4F は厳密にはテストされていないようですが、ほとんど同じ構成のものがテストOKなので大丈夫だろうと思いました。 www.supermicro.com
ちなみに、1世代後の X11SDV シリーズはなぜかSolarisでテストされていませんでした。 www.supermicro.com
SuperMicroに問い合わせてみたところ、「俺たちSolarisでテストするのやめたんだ」という回答が返ってきました。悲しいorz
From: Technical Support <Support@supermicro.com> Subject: RE: Does X11SDV series support Solaris 11? Hi, We stop validating Solaris OS on our new boards. Thanks, -----Original Message----- To: Technical Support <Support@supermicro.com> Subject: Does X11SDV series support Solaris 11? Hi, I am interested in running Solaris 11 on X11SDV series, such as X11SDV-8C-TLN2F. But it does not seem to be tested yet, according to following page. https://www.supermicro.com/support/resources/OS/skylake-d.cfm Are there any plan testing X11SDV series with Solaris 11? Regards,
X11SDVシリーズでもたぶんSolarisは動作すると思うのですが、このシリーズに搭載されている Xeon D-2100 シリーズは、Xeon D-1500 シリーズよりかなり消費電力が上がっていて、低消費電力のモデルがないので、1世代前のX10SDVシリーズを選ぶことにしました。
Xeonにこだわらなければ、DenvertonコアのAtomプロセッサが搭載されている、A2SDiシリーズもいいんじゃないかと思います。 www.supermicro.com
NICの選定もなかなか難しくて、安価な10G NICによく搭載されているAquantiaのチップはSolaris用のドライバがないので、安心なのはIntel X550系のチップになります。Xeon DシリーズやDenvertonコアのAtomは10G NICが統合されているので、Solarisでも動く可能性が高いと思いました。
現時点で、自宅サーバでSolarisを使うなら、SuperMicroのマザーボードは鉄板だと思います。
購入情報
2019/2の時点で、日本での価格は\79,100でした。それに対して、米Amazon.comでは$485で、送料を含めても日本円で約62,000円と、それなりに内外価格差があったので、Amazon.comで買うことにしました。近年、個人輸入の敷居は劇的に下がっている感じがします。
価格.com - SUPERMICRO X10SDV-4C-TLN4F 価格比較
Amazon.com: Supermicro X10SDV-4C-TLN4F Mini-ITX Motherboard : Electronics
マザーボードとしてはかなり高価ですが、XeonとIntelの10G NICが乗ってると思えば、むしろ安く思えてきます。若干感覚が麻痺しているような気もしますが、気のせいということにしましょう。
10G NIC の認識
Solaris 11.4を入れてみて、起動までは問題なくできましたが、10G NICを認識していませんでした。 10G NICを認識させるには、一手間必要でした。
dladmで、1GのNICしか見えていません。
$ dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE net0 Ethernet up 1000 full igb0 net1 Ethernet unknown 0 unknown igb1
prtdiagでは Intel X557-AT2 Ethernet という名前で見えています。
$ prtdiag -v System Configuration: Supermicro Super Server BIOS Configuration: American Megatrends Inc. 2.0a 10/12/2018 BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style) ==== Processor Sockets ==================================== Version Location Tag -------------------------------- -------------------------- Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz CPU1 ==== Memory Device Sockets ================================ Type Status Set Device Locator Bank Locator ----------- ------ --- ------------------- ---------------- DDR4 in use 0 DIMMA1 P0_Node0_Channel0_Dimm0 DDR4 empty 0 DIMMA2 P0_Node0_Channel0_Dimm1 DDR4 empty 0 DIMMB1 P0_Node0_Channel1_Dimm0 DDR4 empty 0 DIMMB2 P0_Node0_Channel1_Dimm1 ==== On-Board Devices ===================================== ASPEED Video AST2400 Intel i350 Ethernet #1 Intel i350 Ethernet #2 Intel X557-AT2 Ethernet #1 Intel X557-AT2 Ethernet #2 ==== Upgradeable Slots ==================================== ID Status Type Description --- --------- ---------------- ---------------------------- 1 available Unknown M.2 PCI-E 3.0 X4 1 available PCI Express Gen3 x16 SLOT7 PCI-E 3.0 X16
scanpciで見ると、Vendor ID は 0x8086、Device ID は 0x15ad のようです。Intelの Vendor ID は製品名にちなんで 8086 なのですね。
# scanpci ... pci bus 0x0003 cardnum 0x00 function 0x00: vendor 0x8086 device 0x15ad Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T pci bus 0x0003 cardnum 0x00 function 0x01: vendor 0x8086 device 0x15ad Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T
こちらのサイトでも確認できます。 pci-ids.ucw.cz
似たようなことを聞いている人がいて、ixgbeドライバで動くんじゃないかとのことなので、ドライバをattachできればよさそうな感じがします。 https://community.oracle.com/thread/4163075community.oracle.com
PCI ID が 8086,15ad のデバイスに、ixgbeドライバをattachする手順は以下のようになります。
/etc/driver_aliases に以下の行を追加します。
ixgbe "pciex8086,15ad"
デバイスを再構成します。
# touch /reconfigure # init 6
もしくは
# reboot -- -r
再起動後、無事に 10G NIC が認識されるようになりました。
$ dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE net0 Ethernet up 1000 full igb0 net1 Ethernet unknown 0 unknown igb1 net3 Ethernet unknown 0 unknown ixgbe1 net4 Ethernet up 10000 full ixgbe0
ドライバがattachされているのがわかります。
$ grep ixgbe /etc/path_to_inst "/pci@0,0/pci8086,6f06@2,2/pci15d9,15ad@0" 0 "ixgbe" "/pci@0,0/pci8086,6f06@2,2/pci15d9,15ad@0,1" 1 "ixgbe"
$ prtconf -D
System Configuration: Oracle Corporation i86pc
Memory size: 16282 Megabytes
System Peripherals (Software Nodes):
...
pci8086,6f06, instance #3 (driver name: pcieb)
pci15d9,15ad, instance #0 (driver name: ixgbe)
pci15d9,15ad, instance #1 (driver name: ixgbe)
...
余談ですが、Solaris 11.4 から path_to_inst は sysobj という仕組みで管理されるようになったようです。いろいろ変わってますね。
というわけで、無事に 10G NIC を使えるようになりました。めでたしめでたし。
現状の構成
現状の自宅サーバの構成は以下のような感じです。この構成で消費電力はだいたい50W前後です。電気代は月800円くらいになるようです。
| 種別 | 品名 |
|---|---|
| Case | Fractal Design Core 500 |
| Power | Corsair SF450 CP-9020104-JP (SFX 450W) |
| MB | SuperMicro X10SDV-4C-TLN4F |
| CPU | Intel Xeon D-1518 (On Board) |
| Memory | SanMax SMD4-U16G48M-24R (DDR4-2400 16GB Micron) |
| Storage | SanDisk 120GB SSD, Western Digital 6TB HDD x2 |
| OS | Solaris 11.4 x86 |
NASとしては若干パワフルすぎますが、Solarisサーバを手元に置いておきたいという手段と目的が入れ替わった状態なのでそれでよいのです。
冷却の注意
このマザーボードはファンレスですが、ファンレスで運用するのはほぼ不可能と思った方がよいです。ケースファンだけで冷却できるかなと思いましたがぜんぜん無理で、アイドル状態でも80℃を超えて温度が上昇してしまう状態でした。
さすがにこれではダメなので、CPUのヒートシンクにファンを取り付けることにしました。6cm角がちょうどよいサイズのようです。 このマザーボードはファンの回転数をPWMだけで制御しており、PWM非対応のファン（3pinのもの）だと全力で回転してしまいます。 6cm角で、PWM対応となるとほとんど選択肢がなく、安心の山洋電機製のものを選びました。
↓のような、PWM非対応のファンをPWM対応にするアダプタを使うのもありだと思います。
![アイネックス 3ピン-PWM4ピン変換制御ケーブル [ 20cm ] CA-PWM](https://m.media-amazon.com/images/I/41jnKzgGI4L._SL500_.jpg "アイネックス 3ピン-PWM4ピン変換制御ケーブル [ 20cm ] CA-PWM")
工作能力が足りないので、↓のような感じで、ビスと輪ゴムで固定しました。見た目はいまいちですが、冷却は充分にできているようです。
ファン付きの、X10SDV-4C+-TLN4F（型番に+が付いてる）というモデルもありますが、このファンはかなりうるさいらしいので、好みに合わせてという感じで。 www.maple-rice.com
zpool remove を試すメモ
Solaris 11.4 では、zpool add したデバイスを remove できるようになっています。以前は zpool add すると外せなかったのでかなりの勇気が必要でしたが、remove できるようになったので構成変更がより柔軟にできるようになりました。
zpoolのバージョンが44以上だと、Device removelという機能が有効になります。
$ zpool upgrade -v ... 44 Device removal ...
こんな感じの構成で、mirror-0 を remove してみたいと思います。上記のサイトの例では、mirror を remove することができるようです。
$ zpool status epool
pool: epool
state: ONLINE
scan: ...
config:
NAME STATE READ WRITE CKSUM
epool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c2t2d0 ONLINE 0 0 0
c2t3d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0
c2t0d0 ONLINE 0 0 0
errors: No known data errors
# zpool remove epool mirror-0 cannot remove device(s): operation not supported on this type of pool
あれれ、remove できませんね。
理由はわかりませんがmirrorはremoveできないのかもしれないので、detachでmirrorを解除してみました。
# zpool detach epool c2t3d0
mirror-0がなくなってディスク1本になりました。
$ zpool status epool
pool: epool
state: ONLINE
scan: ...
config:
NAME STATE READ WRITE CKSUM
epool ONLINE 0 0 0
c2t2d0 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0
c2t0d0 ONLINE 0 0 0
errors: No known data errors
こんどは、残った1本をremoveしてみます。
# zpool remove epool c2t2d0
おっ、コマンドが通りました。
STATEを見るとREMOVINGになっています。
$ zpool status epool
pool: epool
state: ONLINE
status: One or more devices are being removed.
action: Wait for the resilver to complete.
Run 'zpool status -v' to see device specific details.
scan: resilver in progress since Wed Feb 6 21:26:33 2019
10.8G scanned out of 988G at 560M/s, 29m48s to go
0 resilvered
config:
NAME STATE READ WRITE CKSUM
epool ONLINE 0 0 0
c2t2d0 REMOVING 0 0 0
mirror-1 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0
c2t0d0 ONLINE 0 0 0
errors: No known data errors
zpool iostat -v で見ると、少しずつデータが移動しているのがわかります。
$ zpool iostat -v epool 1
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
epool 1023G 5.36T 0 6.73K 0 171M
c2t2d0 - - 0 0 0 0
mirror-1 524G 4.94T 0 6.74K 0 171M
c2t1d0 - - 0 185 0 172M
c2t0d0 - - 0 187 0 174M
-------------------------- ----- ----- ----- ----- ----- -----
...
resilver時はディスクがかなり高負荷になり性能に影響が出ます。I/O負荷が低いときに実施するのがおすすめです。
resilver完了後にzdbで見てみると、mirror-0の部分（children[0]のところ）がpseudoデバイスとして取り込まれているような感じに見えます。 もしかしてashiftが違う（512bセクタと4kbセクタ）HDDが混在していたpoolだったのでこうなったのかもしれません。パフォーマンスに影響が出るかもしれないですね。
$ zdb
epool:
version: 44
name: 'epool'
state: 0
txg: 39458571
pool_guid: 4817329454252204261
timestamp: 1549469022
hostid: 564057
hostname: 'xxxx'
vdev_children: 2
vdev_tree:
guid: 4817329454252204261
id: 0
type: 'root'
children[0]:
guid: 8473064149679056020
id: 0
type: 'pseudo'
path: '$VDEV-C18B8487D547E670'
phys_path: 'epool/$VDEV-C18B8487D547E670'
removing: 1
metaslab_array: 27
metaslab_shift: 33
ashift: 9
asize: 1000191557632
is_log: 0
is_meta: 0
DTL: 5887
create_txg: 4
children[1]:
guid: 16792445297974810689
id: 1
type: 'mirror'
whole_disk: 0
metaslab_array: 111
metaslab_shift: 33
ashift: 12
asize: 5995774345216
is_log: 0
is_meta: 0
create_txg: 23955738
children[0]:
guid: 15198708556418494849
id: 0
type: 'disk'
path: '/dev/dsk/c2t1d0s0'
devid: 'id1,sd@SATA_____WDC_WD60EZRZ-00G_____WD-WX61D68AAPFE/a'
phys_path: '/pci@0,0/pci8086,2036@1f,2/disk@1,0:a'
whole_disk: 1
DTL: 4160
create_txg: 23955738
msgid: 'ZFS-8000-QJ'
children[1]:
guid: 6065348894095674914
id: 1
type: 'disk'
path: '/dev/dsk/c2t0d0s0'
devid: 'id1,sd@SATA_____WDC_WD60EZRZ-00G_____WD-WX61D68AA6EP/a'
phys_path: '/pci@0,0/pci8086,2036@1f,2/disk@0,0:a'
whole_disk: 1
DTL: 5328
create_txg: 23955738
msgid: 'ZFS-8000-QJ'
Build GCC 7 on Solaris 11.3
GCCが7まで出てることにちょっと驚愕しつつ、なんとなくSolarisでコンパイルしてみたメモです。 Solarisを使っているとコンパイルが趣味になりがちです。
GCC, the GNU Compiler Collection - GNU Project - Free Software Foundation (FSF)
環境
$ uname -a SunOS mercury 5.11 11.3 i86pc i386 i86pc Solaris
$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/lto-wrapper Target: i386-pc-solaris2.11 Configured with: /builds/hudson/workspace/nightly-update/build/i386/components/gcc45/gcc-4.5.2/configure CC=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/cc CXX=/ws/on11update-tools/SUNWspro/sunstudio12.1/bin/CC --prefix=/usr/gcc/4.5 --mandir=/usr/gcc/4.5/share/man --bindir=/usr/gcc/4.5/bin --libdir=/usr/gcc/4.5/lib --sbindir=/usr/gcc/4.5/sbin --infodir=/usr/gcc/4.5/share/info --libexecdir=/usr/gcc/4.5/lib --enable-languages=c,c++,fortran,objc --enable-shared --with-gmp-include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as CFLAGS='-g -O2 ' Thread model: posix gcc version 4.5.2 (GCC)
ダウンロード・展開
$ wget http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-7.2.0/gcc-7.2.0.tar.xz ... $ tar Jxvf gcc-7.2.0.tar.xz ... $ cd gcc-7.2.0 ...
依存ライブラリ(gmp, mpfr, mpc, isl)のダウンロード
$ contrib/download_prerequisites ...
configure
$ ./configure \ --prefix=/opt/gcc7 \ --enable-languages=c,c++ \ --enable-shared \ --disable-bootstrap \ --without-gnu-ld --with-ld=/usr/bin/ld \ --with-gnu-as --with-as=/usr/gnu/bin/as \ CC='gcc -m64' CXX='g++ -m64'
オプションはあんまりちゃんと吟味してませんが、なんとなくOS付属のgccを参考にしました。
make
$ gmake -j8 ... $ sudo gmake install ...
/opt/gcc7 配下にインストールされます。
$ /opt/gcc7/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc7/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc7/libexec/gcc/x86_64-pc-solaris2.11/7.2.0/lto-wrapper Target: x86_64-pc-solaris2.11 Configured with: ./configure --prefix=/opt/gcc7 --enable-languages=c,c++ --enable-shared --disable-bootstrap --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as CC='gcc -m64' CXX='g++ -m64' Thread model: posix gcc version 7.2.0 (GCC)
