野辺山で星を見てきました
令和最初の天体観測ということで、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分くらいで気軽に撮影してきたことに価値があると思います。
2日目は池のほとりで一晩中天の川を見ていました。この日は一晩中快晴でした。夏の天の川を見るなら梅雨の前の4月~5月の夜2時~3時頃がおすすめです。池の水面を入れて、星景っぽく天の川を撮影してみました。野辺山は天頂近くは暗いのですが、低空は残念ながら光害がかなりあります。冬場はスキー場の照明でさらに光害がひどいようです。せっかくの星空なのに、残念なところです。
一晩中外にいたらカメラバッグに霜が降りてました。ホームセンターで買った防寒作業着が優秀でした。標高1300mの山と同じようなもんですから、防寒着がなかったら凍死しますね。山での天体観測は凍死との戦いです。
3日目は、北天にカメラを向けてタイムラプス撮影してみました。水面にも星が写っていい絵になるかなと思ったのですが、野辺山上空は飛行機が多すぎでした。人工衛星や流星ぽいものも写ってますね。これはこれでおもしろいです。
3泊中3晩とも晴れて、天体観測を楽しむことができました。3日目は体力が続かず、ほどほどにしてホテルに帰りました。
野辺山高原は首都圏からアクセスしやすい天体観測スポットとしては屈指ではありますが、思ったより低空の光害が目立つと思いました。特に南側が明るいので、天の川の撮影にはあまり向いてないように思いました。空の暗さでは栃木県の戦場ヶ原のほうが暗かったと思います。
戦場ヶ原も南側はそれなりに光害があるので、関東周辺で天の川を撮影するなら千葉の南房総がよいように思います。ただし、南房総も、北側は東京の光害があります。関東周辺で光害がないところはないので、撮影したい対象に応じて撮影場所を選ぶ必要があると思います。
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対応にするアダプタを使うのもありだと思います。
工作能力が足りないので、↓のような感じで、ビスと輪ゴムで固定しました。見た目はいまいちですが、冷却は充分にできているようです。
ファン付きの、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'
紅白歌合戦けん玉ギネスチャレンジ ~コンサル編~
私は誰?
2018/12/31、第69回NHK紅白歌合戦で、三山ひろしさんとともにけん玉ギネス記録を達成した、けん玉ヒーローズのNo.6です。 仕事はエンジニアのようなコンサルタントのようなことをやっています。
序章
2018/11/28、ある知らせが舞い込んできました。「再び、紅白歌合戦の舞台にて、ギネス世界記録に挑戦できることとなりました!!」と。昨年末の残念な結果から11ヶ月、うれしい反面、「今回は絶対に失敗できない」という認識を持ちました。 日本で最も視聴率が高い番組と言ってよい紅白歌合戦の中でのギネスチャレンジという試み、昨年のチャレンジは立派に終えたものの、心ないバッシングがあったのもたしかです。2度目のチャンスが回ってくるという奇跡を裏返すと、今度また失敗すれば一体どれほどの損失になるのか想像できません。 私はいち参加者ですが、けん玉歴は長い方で、参加者の中でも年長者になるので、今回は自分にできることをやろうと思ったのでした。
問題の特定
今回もチャレンジの内容は、けん玉の大皿という技を124人連続で成功するというものです。2017年と同じ内容ですので、2017年と同じようにやれば当然2017年と同じ結果になる可能性が高いと言えます。2017年に成功できなかったのはなぜなのか、まずは問題を特定する必要があります。 ここはギャップ分析というフレームワークを使ってみましょう。
現状認識(AS-IS)
2017年も、年末の12/29にけん玉ヒーローズ約120名のメンバーが招集され、ギネス記録達成に向けた練習が行われました。本番まで当日を含めてもわずか3日しかなく、できることには限りがありました。単にけん玉をやればよいというだけではなく、ステージ上では「演者」であることを求められます。姿勢、表情など、テレビに映るための訓練をしないといけないのです。また、紅白歌合戦は日本最大級の生放送番組でもあります。5時間もの時間、秒刻みのスケジュールで何千人もの人々が動くのです。その中でも最大のグループであるけん玉ヒーローズは、移動のときの隊列の組み方、ステージ上での並び方、ステージからの退出の仕方などを細かく練習する必要があるのです。 そんな中で、何度か124人で大皿を連続で行なう全体練習をやってみたものの、成功しないのです。「大皿」といえば、けん玉の最も基本的な技なので、楽勝ムードが漂っていたように思います。結局、本番を迎える12/31までを通して、成功率は3割程度でした。成功率3割の状態で、生放送一発で成功させるのは無理があったのです。
2018/12/19に紅白歌合戦の番宣のロケを兼ねたリハーサルがあり、集まることができた60名程度で練習を行いました。このときもあまり時間がなく、全体練習を何回かやったのみでした。本番の半分の60人しかいないにもかかわらず、60人連続で大皿を決められた成功率は5割程度でした。 「これでは去年と同じ結果を迎えてしまう。」本番のわずか12日前、我々は、極めて危機的な状況にあったのです。
ゴール設定(TO-BE)
問題を解決するにはゴール設定が必要です。ビジネスだとこれはかなり時間がかかるのですが、今回は明確です。124人連続で大皿を成功できればよいのです。ゴールはより具体的な方がよいので、「紅白歌合戦の本番で、90%以上の確率で、124人連続で大皿を成功させる」というのはどうでしょうか。これなら誰でも理解できるのではないかと思います。
ギャップ
ゴール設定の90%と、現状の30%では、なんと60%もの開きがあります。これが「ギャップ」であり、今回の問題です。大事なのは、問題を当事者が理解できるように整理し、説明して、納得してもらうことにあります。これは問題解決において重要なプロセスです。
問題の深掘り
成功率を高める必要があることはわかりました。では成功率とは何なのかもう少し深掘りしてみたいと思います。 124人連続で成功する全体の成功率をPとして、個々の大皿の成功率をpとすると、Pは以下のように表すことができます。
この式から言えることは、全体の成功率は結果でしかなく、個々の成功率にすべて依存するということです。2017年は全体練習をひたすら繰り返しましたが、個々の成功率には目を向けていませんでした。「木を見て森を見ず」になってはいけないとよく言われますが、この場合は「森を見て木を見ず」のような状態に陥っていたのです。
ではなぜ、個々の成功率が低かったのか、今度はなぜなぜ分析フレームワークを使って考えてみましょう。 分析してみるとなんとなく共通項が見えてきます。「このチャレンジは簡単だと思っていた」というのが根本原因の一つとして挙げられそうです。大皿というけん玉の最も基本的な技を「難しい」と思えるかどうかが本当の難しさだったのだと言えそうです。
上の図はXMindで描きました。フリー版でもかなり使えます。
対応策の提示
なぜなぜ分析より、以下のような対応策が見えてきました。本来はここで見えてくるのは仮説なので、仮説を検証しないといけないのですが、今回は問題が明確なので省略します。
まず、1.は急務と考えました。2018/12/25に以下のような情報の共有を行いました。いろんなエッセンスを詰め込んでみたつもりですが、我々のチャレンジが如何に困難なことであるのかを理解するという意味で、一定のインパクトはあったように思います。
https://www.facebook.com/shakemid/posts/2244599345559437
この時点で本番6日前でした。時間はありませんでしたが、それでもそこから成功率を高められる余地は充分にあると考えました。元々けん玉のレベルがある程度高い人ばかりなので、質の高い練習によって自己鍛錬することができると考えました。
次に、2.ですが、その前に、個々の成功率を高めればよいことはわかったので、どのくらい高めればよいのか考えてみましょう。大皿の成功率で、便宜的に以下のように分けてみようと思います。
カテゴリ | 成功率 | 例示 |
---|---|---|
達人 | 99.99% | 1万回に1回失敗する。高段者、大会上位者など。三山ひろしさんはここ。 |
上級者 | 99.9% | 1000回に1回失敗する。おそらくけん玉ヒーローズのボリュームゾーン。一般的な目で見れば「けん玉名人」。 |
中級者 | 99% | 100回に1回失敗する。2018年のDJ KOOさんはおそらくこのへん。 |
初級者 | 90% | 10回に1回失敗する。2017年のDJ KOOさんはおそらくこのへん。(例に出してごめんなさい。) |
124人全員を達人クラスで集められれば話は簡単なのですが、それはほとんど無理です。12月29日、30日、31日に終日拘束されるのは、一般人でも相当厳しいはずです。また、けん玉の高段者はかなりの部分が小中学生なのですが、出演時間の問題で小中学生は出られません。今回、リザーバー候補も含めて全国から140人集まっていますが、この条件で140人も集まるのがまず奇跡なのです。みなさん、けん玉への愛と、使命感で動いているということを忘れてはいけないと思います。
集まったメンバーの中で達人クラスは、三山ひろしさんを含めて45人前後と見ています。計算上、44人としておきます。このクラスの人は現実的な試行回数で大皿を失敗することはまずありません。残る80人をどうするかが問題です。 初級者クラスの人は残念ながら今回のチャレンジでは戦力になることができません。中級者クラスの99%でもかなりリスクが高いのです。 以下のようなモデルケースを考えてみます。
- 達人: 44人
- 上級者: 78人
- 中級者: 2人
- 初級者: 0人
これで成功率を計算すると、以下のようになり、90%をなんとか超えます。
よって、目標としては、個々の大皿の成功率99.9%以上を目指し、中級者クラスが数人入ってもやむなしとするあたりが妥当な感じがします。
参加者は最低でも中級者以上でないといけないので、以下のような練習方法を提案しました。
- 大皿100回連続成功
- とめけん10回連続成功
同じ大皿でも、漫然とやるのと「100回連続成功する」と意識してやるのとでは、やり方がまったく異なります。100回連続成功するためには、安定が必要です。けんのグリップ、構え、玉を引き上げる軌道、玉をよける軌道、玉を受けるときの膝の使い方などを高度に安定させないと、100回連続は難しいのです。 2018/12/19の練習のときに、三山ひろしさんが来られて「必ず成功する型を見つけるのが重要です」と、仰っていました。三山さんはけん玉の指導員の資格を持っている方なので、よくわかっておられます。それを数値目標にして、より具体化すると「100回連続成功できるような型を見つける」ということになるかと思います。100回連続成功が安定してできるなら、上級者の領域にかなり近いと言えます。
とめけんについては少し毛色が違います。とめけん10回連続成功は、大皿100回連続成功よりも難しいです。けん玉は面白いもので、大皿ばかりやってもなかなか上手くなりません。むしろ上位の技を練習することで、結果的に大皿も上手くなる効果があります。また、とめけん連続成功の10回目はそれなりに緊張感があり、本番を想定したメンタルの強化にも役立ちます。
私が主にやったのはここまでです。 12/29に集合してリハーサルを行う段階で、個別の成功率がどの程度に達しているのかが、結果の明暗を分ける大きな鍵だと考えました。
3.と4.は、進行に大きく関わるので今回のチャレンジの統括者に任せました。今回は強い思いを持って集まったけん玉プレイヤーを選考することになります。選考に落ちた人は非常に苦しい思いをすることは想像に難くありません。けん玉の大会に慣れている人は、予選落ちも経験していると思いますが、そのような経験がない人も多いでしょう。 他人に何らか負担を強いるようなことをお願いするときは、明確に言語化して、事前に書面(できれば対面)で周知して、合意を取ることが納得感につながります。このプロセスは省いてはいけません。
2018/12/29
この日初めて、今回のチャレンジを行う140人が渋谷のNHK放送センターに集まりました。140人ものけん玉プレイヤーが一堂に会すると壮観です。 全体練習の開始前に、統括者より、事前にメンバーの選考を行うことが周知されていました。選考方法は以下のようなものでした。選考の実施は、流れから私が引き受けました。
- 大皿に100回連続挑戦する。途中で失敗したらリザーバー候補に回る。
- 30人ほどのグループに分かれて、順番に大皿を行う。途中で失敗したらリザーバー候補に回る。
- とめけんに連続挑戦する。途中で失敗したらリザーバー候補に回る。リザーバー候補が定員に達するまで繰り返す。
選考1.は私が提案した練習方法と同じものです。よい選考方法とは、以下の2点を満たしている必要があります。(1)はよくわかると思うのですが、意外と(2)には考えが回っていなかったりします。
- (1) 成功率が低い人をふるい落とす
- (2) 成功率が高い人をふるい落とさない
上の方で分けた成功率の人が、大皿100回連続成功できる確率は二項分布によって求めることができます。計算してみると以下のようになります。
カテゴリ | 大皿1回の成功率 | 大皿100回連続の成功率 |
---|---|---|
達人 | 99.99% | 99.0% |
上級者 | 99.9% | 90.5% |
中級者 | 99% | 36.6% |
初級者 | 90% | 0.027% |
二項分布の計算サイト https://keisan.casio.jp/exec/system/1161228843
この選考で、中級者以下の大部分をふるい落とすことができ、上級者以上はほぼ落ちないと期待できるので、妥当性はありそうです。 ちなみに、ほぼ確実に99%以下の成功率の人をふるい落とすには膨大な試行回数が必要になります(失敗する確率1%、95%信頼区間、誤差10%で計算すると38000回くらい)。さすがにこれは現実的な時間ではできません。大皿という極めて成功率が高い技で差を付けるのは難しいのです。興味のある方は、大数の法則やベルヌーイ試行のあたりを調べてみてください。
実際にこの選考で落ちてしまったのは140名中5名でした。去年の感じだと30名前後落ちてもおかしくないと考えていたので、これはうれしい誤算です。みなさんかなり練習を積んできているのだと期待できました。 反面、選考はより過酷で、理不尽なものになることを意味していました。大皿がきちんとできる人を落とさなければいけないということだからです。
選考2.では1人も落ちませんでした。本番に近い緊張感を得るには悪くありませんが、個々の大皿の試行回数は少なくなるので、選考方法としてはあまりよくなかったようです。
選考3.は非常に厳しいものでした。大皿で決まらない以上、技の難易度を上げる必要はあるのですが、とめけんは大皿とは特性が異なるのです。大皿の成功率ととめけんの成功率には強い相関があると想像できますが、とめけんは達人クラスでも99%以上の成功率にすることが難しいのです。これは、玉を引き上げた後の調整がほとんどできないことに起因するのですが、そこが大皿とは決定的に違います。(上級者クラスになると、むしろとめけんよりふりけんのほうが成功率が高くなります。) そのため、連続成功だと、どんなに上手い人でも外してしまうリスクがあります。技術よりも、むしろ度胸試し・運試しの要素が強くなってしまうのです。上記の、条件(2)を満たせない可能性が大いにあるのですが、このときはこのやり方でやると周知している以上、このやり方でやるしかありませんでした。 不安は的中し、世界クラスのけん玉プレイヤーを選考で落としてしまうことになりました。
選考後には様々な人間模様がありました。泣き出す人、納得できずその場を去る人、リザーバーになったときのために練習をする人、自分の実力を認め進んでサポート役に回る人など、これは一言では言い表せないものがあります。私自身、けん玉の大会に遠征して、予選落ちした経験もありますので、似たような状況は想像できますが、今回はそれが3日間続くので、プレッシャーは相当なものだったと思います。
続いて、全体練習に入りました。けん玉を、武道やスポーツでよく用いられる「心技体」のフレームワークに当てはめて考えてみると、今回は「体」はほぼ関係ありません。「技」については、上記の練習と選考でかなり高められると考えられます。残る「心」については、打ち手を考える必要がありました。 2017年に失敗した方は、練習では1度も失敗しなかったにもかかわらず、本番で震えて頭が真っ白になってしまい、失敗したといいます。上の方で言及したゴール設定の「紅白歌合戦の本番で、90%以上の確率で、124人連続で大皿を成功させる」の「紅白歌合戦の本番で」という部分です。
プレッシャーのかかる状況で技を成功させるには、場慣れするのが最もよいのですが、そのような時間はありません。2017年の経験者も多いですが、今回初めて参加するメンバーも相当数いました。 本番では、当然ですが1回でも失敗すればそれで終わりです。そのため、練習においても1回でも失敗すれば何かが起こる仕組みを作る必要がありました。 検討の結果、選考に落ちた人の中からリザーバー候補を選出しておき、全体練習で1回でも失敗すれば、その場でリザーバーと交代するというやり方で進めることになりました。 これは、リザーバー候補にはチャンスになりますが、いったん選考に通ったメンバーには非常に強いプレッシャーになります。本番までの3日間、本番と同等の「1回失敗したら終わる」というプレッシャーに慣れていただく必要があったのです。
この日は、板踏み(ステージでのリハーサル)を含めて、10回の全体練習を行い、いずれも124人連続で大皿を成功することができました。リザーバーとの交代はありませんでした。当初目標の成功率9割は確保できているように思いました。少なくとも、2017年は3割程度しか成功していなかったので、明らかに違ったと言えます。
2018/12/30
この日も、全体練習を開始する前に、大皿を100回連続で成功する選考を行いました。成功率を高く維持する必要があるのと、成功率を見極める試行回数は多いほど正確になるからです。 選考の結果、2名が失敗し、リザーバー候補と交代になりました。また、1名遅刻者が出たので、その1名もリザーバーと交代になりました。
この日の全体練習の5回目、29日から数えると15回目に、1名が大皿を失敗しました。全体練習での失敗はこれが初めてでした。大皿の試行回数はこの時点で 124*15=1860回になり、個々の大皿の成功率は 1-1/1860≒0.9995=99.95% に達していることが伺えました。これほどの成功率でも大数の法則により、試行回数を重ねると失敗が現れます。
全体練習では個々の成功率を上げる効果はあまりありませんが、全体の成功率の確認と、本番へのプレッシャーへの慣れのためにある程度繰り返す必要があります。29日から累積で20回の全体練習を行い、失敗したのは上記の1回のみでした。本番まであと1日、非常に高いレベルで仕上がっている手応えを感じました。
上記の失敗の内容は、引き上げた玉がけん先にぶつかるというものでした。実は1日前の板踏みの際にも危ない場面があり、けん先にぶつかった後かろうじてキャッチしているところを見ていました。99.9%の成功率でもこれはあり得るのです。けん先を避ける技術はあるので、伝えようか迷いましたが、フォームを変えることになるので、一時的に成功率が落ちるリスクもあります。しかし、2度あることは3度あると考え、以下の動画を公開することにしました。中皿を上にして構えれば、けん先に玉をぶつけることはまずなくなります。後で何人かから参考になったと言っていただけたので、公開してよかったのかなと思います。
2018/12/31
この日は本番を迎えるのみでした。全体練習を5回行って失敗はなく、最終的に25回全体練習を行って24回成功していました。極めて特殊な状況下で、プレッシャーに耐え、皆さんよくがんばったと思います。心・技ともに非常に高いレベルでまとまっていたように思います。 本番は承知のとおり、危なげなく成功することができました。終わるタイミングまで完璧で、練習でも出たことがないほどの出来でした。本番で練習以上のものが出るのは、質の高い練習と、高い集中状態が重なった理想的な状態だったということに他ならないと思います。しかし、そこまで行ってようやく「人事を尽くして天命を待つ」といえる状態で、運命を引き寄せることが出来て本当によかったと思います。
ステージ上で私は6番目でしたが、自分が成功したあと、半分を過ぎたあたりで成功を確信し、ステージ上で泣いていました。映ってないと思いますのでご勘弁いただきたいところです。
総括
けん玉ギネスチャレンジをコンサル的な視点で振り返ってみました。 けん玉ギネスチャレンジを通して、「数値目標の力」というものを感じていただけたのではないかと思います。これはビジネスにも使えるものだと思いますので、何かの機会に思い出していただけますと幸いです。
ぷららのIPoEでIPv4 over IPv6を使いつつPPPoEも共存させるメモ
概要
近頃、夜間や休日などの混雑時間帯にあまりにインターネット接続の速度が遅いのでIPoE方式にしてみようと思いました。 これは、一般的な家庭である我が家でIPoE(IPv4 over IPv6)を導入したときのメモです。
元々の環境
元々のインターネット接続環境は以下のような感じです。
ぷららではIPoEサービスを「ぷららv6エクスプレス」という名前で提供しています。 2018/3/1以降にぷららに申し込んだユーザは自動的に有効になるようですが、それ以前からのユーザはマイページから自分で申し込む必要があります。 私はマイページで申し込んでから2日ほどで開通のお知らせメールが来ていました。 「ぷららv6エクスプレス」については、↓のページに説明があります。 www.plala.or.jp
機器の購入
IPoEでIPv6インターネットに接続するには、Web Caster V120でも問題ありません。IPoEが開通すると、特に何もしなくてもIPv6でつながるようになります。 しかし、IPoEでIPv4インターネットに接続するには、「IPv4 over IPv6」が必要になります。IPv4 over IPv6の方式にはDS-Lite方式やMAP-E方式などいくつかの方式があります。ぷららは方式を非公開にしていますが、MAP-E方式のサービスの1つである「OCNバーチャルコネクト」を使用しているようです。 OCNバーチャルコネクトを使用するには専用機器が必要で、今のところ「ドコモ光ルーター01」しか対応していないようです。
「ドコモ光ルーター01」はNECのAterm WG1200HPのOEM製品のようですが、ファームウェアは別物のようで、各社のIPv4 over IPv6方式に対応しているようです。無線LANルータとしてはやや割高な気はしますが、これしかないので仕方がありません。
構成の問題
さて、家庭内からインターネットに向けて接続するだけなら、Web Caster V120をドコモ光ルーター01に入れ替えてしまえばよいのですが、そう簡単にはいきません。問題点は以下の2つです。
自宅サーバはダイナミックDNSで外にIPアドレスを公開しているのですが、IPoEだとIPv4アドレスの使用には制限があります。OCNバーチャルコネクトだと、公開できるポートが限られているようでした。少なくともWebやメールで使うようなWell-Knownポートは使えません。そのため、外部に公開するIPアドレスを使用するには、PPPoE接続を残さなければいけません。 また、Web Caster V120はVoIPゲートウェイの機能を内蔵しており、我が家では電話機をつなげています。これがないと、ぷららフォン for フレッツを使用できません。あまり使うことはないのですが、それでもたまに使うのでなくすわけにもいきません。
構成案
というわけで、Web Caster V120は残しつつ、ドコモ光ルーター01を追加して、PPPoE接続かIPoE接続かを選択できるようにする方式が最もよさそうです。図にすると↓のような感じです。
VDSLモデムのLANポートは1つしかないので、WAN側にL2スイッチを挟んでWeb Caster V120とドコモ光ルーター01を接続することにしました。LAN側は、2つの機器を同一のネットワークに置いて、配下の機器ごとにデフォルトゲートウェイを選択することで接続方式を分けられるようにしました。
具体的な設定
Web Caster V120では、IPv6ブリッジ機能を無効にしておきます。これで、IPv6での通信はドコモ光ルーター01側からになります。
ドコモ光ルーター01は起動時に接続方式を自動判定します。IPoE接続は、手動では設定できないようでした。
自動判定で何をやっているのかはわかりませんが、おそらく取得したIPv6アドレスのレンジからIPoE接続事業者(VNE)を判定しているのではないかと思います。ぷららの場合は「OCNバーチャルコネクト」と判定されました。再起動を促されるので再起動します。
再起動すると、動作状態が「OCNバーチャルコネクト」になりました。これで、IPv4 over IPv6が使えるようになっています。
IPoEの動作確認は↓のサイトを使うと便利です。 ipv6-test.com
まずは、デフォルトゲートウェイをWeb Caster V120側(PPPoE接続)にした場合は以下のようになりました。IPv4アドレスがぷららのものになっているのがわかります。
続いて、デフォルトゲートウェイをドコモ光ルーター01側(IPoE接続)にした場合は以下のようになりました。IPv4アドレスがOCNのものになっているのがわかります。
Googleの「インターネット速度テスト」で速度を測ってみました。結果は一目瞭然で、IPoEが圧倒的に速いです。計測したのは土曜日の23時台なので混雑している時間帯だと思います。今はまだ設備が空いているからだとも言えますが、VDSLの限界の100Mbpsに迫る速度が出ていて驚きました。
というわけで、IPoE接続でIPv4 over IPv6を使いつつ、PPPoE接続も共存させることができました。 しかし、IPoEを巡る状況はずいぶん複雑になってるのですね。一般的なネットワークエンジニアならわかると思いますが、一般的な人にこれを理解してもらうのはかなり難しいように思います。
Kenko スカイメモS に Vixen ポーラメーターを取り付ける
Kenko スカイメモSにVixen ポーラメーターを取り付けてみたメモです。
Kenko ポータブル赤道儀 スカイメモS シルバー 455166
- 出版社/メーカー: ケンコー
- 発売日: 2015/04/21
- メディア: Camera
- この商品を含むブログ (1件) を見る
Vixen ポータブル赤道儀 星空雲台ポラリエ(WT) ホワイト 355051
- 出版社/メーカー: ビクセン
- 発売日: 2011/11/30
- メディア: エレクトロニクス
- 購入: 1人 クリック: 41回
- この商品を含むブログを見る
4年ほど遠征用の赤道儀としてVixen ポラリエを使ってきましたが、Kenko スカイメモSがどうしても気になってしまったので購入してしまいました。スカイメモSはポラリエと同価格帯のポータブル赤道儀ですが、後発だけあってポラリエより優れている点がいくつかあります。ポラリエもオプションで機能拡張できるのですが、本体に対してかなり高価な感じがするのでスカイメモSはお買い得かなと思います。
ポラリエ | スカイメモS | |
---|---|---|
実売価格 | 37000円前後 | 35000円前後 |
耐荷重 | 2kg(オプション追加で6.5kg) | 5kg |
極軸望遠鏡 | オプション(約30000円) | 付属 |
電源 | 単3乾電池2本で2時間 | 単3乾電池4本で72時間 |
ポラリエにあってスカイメモSにないのは方位磁石くらいかなと思います。ポラリエにはポーラメーターというオプションがあり、北極星が見えなくてもある程度の精度で設置することができます。
Vixen 天体望遠鏡アクセサリ ガイダー ポーラメーター ポラリエ撮影用 35511
- 出版社/メーカー: ビクセン
- メディア: Camera
- 購入: 3人 クリック: 8回
- この商品を含むブログを見る
スカイメモSにこんな感じで取り付けられたらいいなあと思いました。ポーラメーターはカメラのアクセサリーシューに取り付けられるようになっているので、スカイメモSにアクセサリーシューを取り付けてみることにしました。
材料はこんな感じです。
エツミのE-6617は1/4インチネジ(カメラネジ)でアクセサリーシューを取り付けることができます。私が持っていたのはE-6117という旧製品で、ネジ穴が貫通しているところが違うようです。
- 出版社/メーカー: エツミ
- 発売日: 2014/10/10
- メディア: Camera
- この商品を含むブログを見る
インチネジはホームセンターではなかなか売ってないのでモノタロウで購入しました。長さは3/8インチのものにしました。 www.monotaro.com
ピンバイスで電池ボックスのふたに穴を開けます。
開けました。
さらに、リーマーで穴を拡げます。だいたい直径7〜8mmくらいが良いと思います。拡げすぎには要注意です。
拡げました。きれいに仕上げたい方はヤスリがけしてください。
アクセサリーシューをネジ止めします。かなりがっちり止まります。
裏側はこんな感じです。
ネジの頭が少々浮いていますが、このくらいなら電池に干渉しませんでした。電池とふたの間の余裕があまりないので、見極めながら穴を拡げてください。
電池ボックスにふたをするとこんな感じです。
ポーラメーターを取り付けるとこんな感じです。うーん、まるで純正品のような自然さ。
というわけで、スカイメモSにポーラメーターを取り付けてみました。これで、たとえば日食のときなど北極星が見えなくてもある程度極軸を合わせることができます。
余談ですが、スカイメモSは日本ではKenkoがスカイメモSという商品名で販売していますが、元はSky-WatcherのStar Adventurerという製品です。本体の販売価格は、日本と海外であまり変わらないですが、微動台座などのオプションは海外の方がだいぶ安いようです。少しの価格差なら日本の代理店経由で買う方が安心感があるかもしれませんが、さすがに倍とかになると、送料を考慮しても海外サイトで購入した方がお得な気がします。