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に登壇した日本人はいっぱいいますが、けん玉をやった人はいないでしょう。

View this post on Instagram

A post shared by 嶋寺 克彰 (@shakemid)

Oracle Open World 2019 の資料はこちらのサイトからダウンロードできます。（英語版です）

events.rainfocus.com

2019/8に日本で開催された、Oracle Modern Cloud Day Tokyoでも、同じ内容を日本語でお話しさせてもらったので、そちらの資料を使って解説したいと思います。

View this post on Instagram

A post shared by 嶋寺 克彰 (@shakemid)

Oracle Modern Cloud Day Tokyo の資料はこちらのサイトからダウンロードできます。

https://www.oracle.co.jp/campaign/moderncloudday/2019/

導入

表紙の背景に特に意味はありませんが、自分で撮影してきた天体写真をぶっ込むスタイルでいきました。この写真は2017年8月にアメリカで撮影してきた皆既日食の写真です。OOWで皆既日食を見た人がいるか聞いてみたら、2,3人手を上げてくれました。

余談ですが、2017/8/21 北米皆既日食の記事はこちら。

shakemid.hatenablog.com

自己紹介スライドはいつもながら自己主張強めです。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番目に「セキュリティ＆ガバナンス」を挙げています。

www.gartner.com

アプリケーションコンテナのセキュリティと一言に言っても、どうすればいいのかなかなか難しいです。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はかなりセキュリティに振り切ったコンテナランタイムだと言えます。

katacontainers.io

この図は、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リポジトリを有効化します。

# 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

相貌失認

相貌失認（そうぼうしつにん）をご存じでしょうか。

相貌失認は高次脳機能障害の一種で、人の顔を覚えられない、人の表情がわからないといった症状があります。 人口の2%が該当するとも言われ、意外と多いです。程度は様々で、重症だと家族の顔すら覚えられないこともあるそうです。治療法は基本的にはありません。

私は軽度の相貌失認を自認しています。

ja.wikipedia.org

ブラッド・ピットなど、相貌失認を告白している著名人もいます。この人がブラッド・ピットだと、皆さんわかるのだと思いますが、たぶん私は目の前にいてもわかりません。

movie.walkerplus.com

私はまったく覚えられないわけではないので、軽度なのだと思いますが、以下のようなことがよくあり、困ることがあります。

• およそ3人～4人に1人は顔を覚えるのが非常に難しい。法則性は特になし。
• 仕事で顔を合わせていても、街中など、違う場面だと誰かわからない。
• 大勢の中から目的の人を探せない。オープンスペースのようなところで待ち合わせると詰むことあり。
• 2回目以降会っても誰かわからない。何回も会っている人でも、初めて会うのか会ったことがあるのかわからない。
• 芸能人の顔がわからない。映画などで役柄はわかっても、誰なのかわからない。

こちらのサイトで、相貌失認のセルフチェックができるサイトが紹介されていました。ふつうの人だと平均80%で、60%を切ると相貌失認の疑いありとのことなのですが、私がやってみたところ50%ほどでした。まあまあの相貌失認なのだと思います。

www.gizmodo.jp

テストはこちらのサイトです。（英語です）

www.bbk.ac.uk

治療法はないので、受け入れるしかないのですが、自分が他人の顔を覚えられないので、なるべく自分が覚えていただけるように心がけていることから、自己主張が強めに感じる方もいるかもしれません。 街中など、たくさんの人がいる中で私に会って、無視しているように見えても、おそらく顔を認識できていないので、気を悪くしないでいただけるとありがたいです。

こうして相貌失認のことを書けば、少しは世の中の役に立つかもしれないので、書かせていただきました。

ZWO ASIAIR + Sky-Watcher SynScan Wi-Fi + EQ5GOTO で自動導入

概要

ZWO ASIAIR と Sky-Watcher SynScan Wi-Fi を組み合わせて、 EQ5GOTO で自動導入できるところまで検証してみたメモです。

ASIAIR は1年ほど前からアマチュア天文界で話題になっているデバイスで、天体写真に必要な、カメラや赤道儀の操作を、スマートフォンやタブレットでまとめてできてしまうという画期的な製品です。私は Sky-Watcher EQ5GOTO を、SynScan Wi-Fi でスマートフォンから操作できるようにしていたので少し様子見していましたが、ASIAIRは23,000円とこの手の製品にしては安いので気付いたら買っていました。

http://hoshimiya.com/?pid=133669448hoshimiya.com

hoshimiya.com

Sky-Watcher EQ5 GOTO赤道儀（ステンレス三脚仕様）

通常は ASIAIR と EQ5GOTO の接続は、ハンドコントローラにシリアルケーブルを挿して有線で連携するのですが、どうせなら無線で連携したいと思いました。 ASIAIR と AZ-GTi での連携は公式にサポートされていたので、中身がほとんど同じと思われる SynScan Wi-Fi との連携もできるだろうと思いました。

https://astronomy-imaging-camera.com/manuals/ASIAIR_Sky-Watcher_AZ-GTI.pdf

ZWO社のFacebookページで、AZ-EQ5GT での動作報告例があったので、私も EQ5GOTO での動作報告を共有しておきました。

www.facebook.com

シナリオ

設定の手順を簡単に解説します。無線LANの設定のところが少々ややこしいかもしれません。私は、光学や制御のことはさっぱりですが、ネットワークのことは仕事上得意分野です。最近のアマチュア天文界はIT化が著しいようなので、私にはありがたいかもしれません。

私はiPadで検証したので、画面はiPadのものですが、たぶんAndroidでもだいたい同じ手順でいけると思います。

SynScan Wi-Fi の設定

iPad/iPhone を、SynScan Wi-Fi のSSIDで無線LANに接続し、SynScan Pro App で SynScan Wi-Fi に接続します。

SynScan Wi-Fi は、アクセスポイントモード（無線LAN親機）として動作していますが、ASIAIR と同じネットワークセグメントに接続するために、ステーションモード（無線LAN子機）に変更します。ASIAIR のSSIDとパスワード（ASIAIRの本体側面に記載）を入力し、固定IPアドレスを割り当てます。ここでは 10.0.0.10 に設定します。

「Apply（適用）」を押すと設定が反映され、以後は、ASIAIRを無線LAN親機として接続するようになります。設定を間違えると、SynScan Wi-Fi に接続できなくなるので慎重に設定してください。

もし設定を間違えたら、SynScan Wi-Fi をリセットする必要があります。説明書によると、SynScan Wi-Fi をリセットするには、電源を入れて接続せずに1時間放置すればよいようです。（なんという仕様...）

ASIAIRの設定

iPad/iPhone を、ASIAIR のSSIDで無線LANに接続します。デフォルトでは、ASIAIRの無線LANの周波数帯は5GHzになっていますが、SynScan Wi-Fiは2.4GHzにしか対応していないので、2.4GHzにしておいてください。そもそも、日本では電波法により屋外で5GHz帯は使ってはいけないので、おとなしく2.4GHzにしておきましょう。

SynScan Pro App でのアラインメント

iPad/iPhone を ASIAIR のSSID（ASIAIR_xxx）に接続したら、SynScan Pro App で SynScan Wi-Fi に接続してください。設定がうまくいっていれば、10.0.0.10 で SynScan Wi-Fi に接続できると思います。

SynScan Pro App で、アラインメントを行ってください。3スターアラインメントが推奨らしいのですが、ASIAIRの Plate Solving が優秀なようなので1スターアラインメントでも十分な気がします。アラインメントを行わないと、ASIAIR から接続ができないようです。

ASIAIR から SynScan Wi-Fi への接続

ASIAIR のアプリに切り替えて、望遠鏡のアイコンを選択し、以下のように設定して SynScan Wi-Fi に接続してください。

• Telescope: EQMod Mount (SynScanではなく)
• IP: 10.0.0.10
• Port: 11880
• Protocol: UDP

接続がうまくいけば、ASIAIRから自動導入などが行なえるようになります。

まずはここまでしか検証できていませんが、オートガイドや Plate Solving など、魅力的な機能が他にもあるので、徐々に試したいと思います。

野辺山で星を見てきました

令和最初の天体観測ということで、GWの後半は3泊4日で野辺山高原に出かけてきました。 野辺山は首都圏からアクセスしやすい天体観測スポットで、私が住んでいる千葉県浦安市からだと車で3～4時間ほどで行くことができます。 www.kanko-nobeyama.jp

野辺山には2014年にも来たことがあるのですが、そのときは1泊だけで、残念ながら夜は曇ってしまい星を見ることができませんでした。約4年半ぶりのリベンジです。

撮影場所は、野辺山駅から車で5分くらいのところにある、八ヶ岳ふれあい公園にしました。24時間無料で使える駐車場とトイレがあり、天体観測スポットとして人気があるようです。深夜でも常に星を見に来ている人がいました。

公園には1周500mの大きな池があります。水面を使った星景写真を撮るのも面白いと思います。

妙に整った形の池だと思ったら、もともとはスケートリンクだったとのことです。

こんな感じの清掃の行き届いたトイレが24時間使えます。管理人さんが常駐しているようです。

今回の装備です。1日目は、 BORG 71FL＋α7S＋EQ5GOTO で、主に系外銀河を狙いました。BORG 71FLは400mmしかないので系外銀河を撮影するにはちょっと小さいです。系外銀河をちゃんと撮影しようとするとさらに上の機材が必要ですが、比較的コンパクトな機材で10分くらいで気軽に撮影してきたことに価値があると思います。

View this post on Instagram

A post shared by 嶋寺 克彰 (@shakemid)

2日目は池のほとりで一晩中天の川を見ていました。この日は一晩中快晴でした。夏の天の川を見るなら梅雨の前の4月～5月の夜2時～3時頃がおすすめです。池の水面を入れて、星景っぽく天の川を撮影してみました。野辺山は天頂近くは暗いのですが、低空は残念ながら光害がかなりあります。冬場はスキー場の照明でさらに光害がひどいようです。せっかくの星空なのに、残念なところです。

一晩中外にいたらカメラバッグに霜が降りてました。ホームセンターで買った防寒作業着が優秀でした。標高1300mの山と同じようなもんですから、防寒着がなかったら凍死しますね。山での天体観測は凍死との戦いです。

View this post on Instagram

A post shared by 嶋寺 克彰 (@shakemid)

3日目は、北天にカメラを向けてタイムラプス撮影してみました。水面にも星が写っていい絵になるかなと思ったのですが、野辺山上空は飛行機が多すぎでした。人工衛星や流星ぽいものも写ってますね。これはこれでおもしろいです。

3泊中3晩とも晴れて、天体観測を楽しむことができました。3日目は体力が続かず、ほどほどにしてホテルに帰りました。

野辺山高原は首都圏からアクセスしやすい天体観測スポットとしては屈指ではありますが、思ったより低空の光害が目立つと思いました。特に南側が明るいので、天の川の撮影にはあまり向いてないように思いました。空の暗さでは栃木県の戦場ヶ原のほうが暗かったと思います。

shakemid.hatenablog.com

戦場ヶ原も南側はそれなりに光害があるので、関東周辺で天の川を撮影するなら千葉の南房総がよいように思います。ただし、南房総も、北側は東京の光害があります。関東周辺で光害がないところはないので、撮影したい対象に応じて撮影場所を選ぶ必要があると思います。

Elasticsearch Cluster on Linux Container

概要

Linuxコンテナ（systemd-nspawn）を使って、複数ホストにまたがるElasticsearchクラスタを構築してみました。 私はコンテナ歴12年くらいですが、ほとんどSolarisコンテナ（Zones）ばかり使っていて、Linuxコンテナはどんなものかよくわかっていないので、おかしなことを言っていましたらご指摘ください。

背景

以下のような感じの要件で、基盤のアーキテクチャを考えていました。

1. 50～100ノード規模のElasticsearchクラスタを作りたい
2. オンプレ環境で
3. 一度起動したら年単位で動き続ける
4. 商用ライセンスはあまり使いたくないけど、人柱になって自力でなんとかする気概はあり

なんとなく以下のような実現方式を考えました。本音はSolaris Zonesを使いたくてたまりませんが今回はLinux縛りです。

カテゴリ	方式	評価（主観）
物理系	物理サーバ50台	× ラックが足りない。運用嫌だ。
	物理サーバ＋マルチプロセス	△ 運用嫌だ。
ハイパーバイザ系	VMware	△ ライセンス必要。オーバーヘッド嫌だ。
	KVM, Xen	△ オーバーヘッド嫌だ。
コンテナ系	Docker	△ どうも合わない。k8s, Swarmとかは大がかりすぎ。
	OpenVZ	△ まだあるのだろうか？
	LXD	○？ 良さそう。使うならUbuntuが良さそうか。
	systemd-nspawn	○？ ほぼOS標準の機能！

Dockerは少し検証してみたのですが、動くには動くのでしょうが、ホストまたぎのネットワークを構成するのが面倒で、KVSを立ち上げて、VXLANでオーバーレイネットワークとかになるのでやる気がなくなりました。 そのためだけにKubernetesとかSwarmを使うのも大がかりすぎに思えました。

qiita.com

DockerをDisる気はなく、用途がマッチすれば良いと思いますが、仮想マシンのようなことがやりたいならまったく不向きで、無理矢理使っても悲惨な運用になるのが落ちという感じがします。 長年Solarisコンテナを使ってきたのもあって、なるべくシンプルでほぼOS標準の機能で動作するということから systemd-nspawn にたどり着き、検証してみようと思いました。

なお、クラウド前提なら、Amazon Elasticsearch Service を検討するのもいいと思います。

aws.amazon.com

シナリオ

今回構築する環境は以下のようなイメージです。物理マシンがあれば使ってもいいですが、私はVirtualBox上に構築することにしました。

構築は以下のような流れで進めました。

• ホスト構築編
  • CentOS 7 をインストールする
  • systemd-networkd をインストールする
  • ZFS をインストールする（任意）
• コンテナ構築編
  • コンテナイメージをインストールする
  • コンテナを起動する
  • Elasticsearchをインストールする
  • コンテナをコピーする

構築

ホスト構築編

CentOS 7 をインストールする

OSはユーザが多いであろうCentOSにしました。バージョンは現時点で最新の7.6にしました。

インストールはできましたが、グラフィカルインストーラだとマウスでボタンをクリックできないことがある謎の事象に遭遇したので、テキストインストーラを使う方がいいような気がします。

qiita.com

今回はホスト間で通信できる必要があるので、VirtualBoxのネットワークの設定でブリッジアダプターを使うとよいと思います。また、プロミスキャスモードを許可する設定も必要です。

また、OSの領域とコンテナの領域を分けたいので、ストレージの設定画面でディスクイメージを1つ追加しました。

SELinuxは無効にしました。

$ sudo vi /etc/sysconfig/selinux
----
...
SELINUX=disabled
...

systemd-networkd をインストールする

今回はホスト間で通信できるようにネットワークブリッジを使うので、ネットワークの管理をsystemd-networkdで行うのがよいようです。以下のページを参考にしました。

renediepstraten.nl

以下のページも参考にしました。systemd関連のドキュメントはArch Linuxのものがわかりやすい感じがします。

wiki.archlinux.jp

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 の公式の手順に従ってインストールします。

github.com

ZFSのYumリポジトリを使えるようにします。

$ 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文字以下にするのが無難なようです。

github.com

コンテナ構築編

コンテナイメージをインストールする

systemd-nspawn では、コンテナイメージをインストールする方法は主に3種類くらいあるようです。

1. yum install --installroot でインストールする。chroot環境を作るのと似た感じ。
2. ビルド済みのイメージを使う。Dockerのイメージも使えるようだ。
3. すでに作成済みのコンテナからコピーする。

ひとまずオーソドックスな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 のページがわかりやすいと思います。

wiki.archlinux.jp

Elasticsearchをインストールする

ホスト側で、vm.max_map_countの値を増やしておきます。

$ sudo vi /etc/sysctl.d/10-vm.conf
---
vm.max_map_count=262144

$ sudo sysctl -p

Elasticsearchのyumリポジトリを追加します。

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 も考慮した方がよいと思います。

www.elastic.co

サービスを有効にします。

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のクローン機能を使って作りました。以下のあたりに気をつければ良いと思います。

• ホスト
  • ホスト名変更: hostnamectl set-hostname ...
  • machine-id変更: rm /etc/machine-id; systemd-machine-id-setup
  • IPアドレス変更: /etc/systemd/network/ 以下
  • ブリッジのMACアドレス変更
  • zpoolのimport: zpool import -f tank
• コンテナ
  • コンテナ名変更: zfs rename
  • IPアドレス変更
  • ElasticseachのID情報削除

クラスタの状態を確認すると、無事に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 が動作したのでメモしておきます。

www.supermicro.com

私の家の自宅サーバはかれこれ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

マザーボード選定の経緯

要件は↓のような感じです。

1. 小型がいいのでMini-ITXで
2. CPUはXeonで
3. なるべく省電力で
4. IPMIでリモート管理ができて
5. 10G NIC が付いてて
6. 当然Solarisが動くこと

この条件だと選択肢はほぼ 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シリーズを選ぶことにしました。

www.servethehome.com

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 という仕組みで管理されるようになったようです。いろいろ変わってますね。

docs.oracle.com

というわけで、無事に 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対応となるとほとんど選択肢がなく、安心の山洋電機製のものを選びました。

オウルテック PCケース用山洋電気製標準PWMファン 6cm 25mm厚 1000~4600rpm F6-PWM

↓のような、PWM非対応のファンをPWM対応にするアダプタを使うのもありだと思います。

アイネックス 3ピン-PWM4ピン変換制御ケーブル [ 20cm ] CA-PWM

工作能力が足りないので、↓のような感じで、ビスと輪ゴムで固定しました。見た目はいまいちですが、冷却は充分にできているようです。

ファン付きの、X10SDV-4C+-TLN4F（型番に+が付いてる）というモデルもありますが、このファンはかなりうるさいらしいので、好みに合わせてという感じで。 www.maple-rice.com

SUPERMICRO X10SDV-4C-TLN4F - Motherboard - mini ITX - Intel Xeon D-1518 - USB 3.0 - 2 x 10 Gigabit LAN, 2 x Gigabit LAN - onboard graphics

SUPERMICRO X10SDV-4C+-TLN4F - Motherboard - mini ITX - Intel Xeon D-1518 - USB 3.0 - 2 x 10 Gigabit LAN, 2 x Gigabit LAN - onboard graphics

zpool remove を試すメモ

Solaris 11.4 では、zpool add したデバイスを remove できるようになっています。以前は zpool add すると外せなかったのでかなりの勇気が必要でしたが、remove できるようになったので構成変更がより柔軟にできるようになりました。

docs.oracle.com

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'