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上に構築することにしました。 f:id:shakemid:20190407085152p:plain

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

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

構築

ホスト構築編

CentOS 7 をインストールする

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

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

qiita.com

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

また、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にします。

ZFSCentOSで使用するには、カーネルモジュールを追加する必要があります。ZFS on Linux の公式の手順に従ってインストールします。

github.com

ZFSYumリポジトリを使えるようにします。

$ 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 に付属のものはバージョンが古いのかそのオプションがありません。

https://jlk.fjfi.cvut.cz/arch/manpages/man/machinectl.1.html

仕方がないので、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 ...
    • 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

ぷららの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」はNECAterm 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接続かを選択できるようにする方式が最もよさそうです。図にすると↓のような感じです。 f:id:shakemid:20180907042950p:plain

VDSLモデムのLANポートは1つしかないので、L2スイッチを挟んでWeb Caster V120とドコモ光ルーター01を接続することにしました。2つの機器を同一のネットワークに置いて、配下の機器ごとにデフォルトゲートウェイを選択することで接続方式を分けられるようにしました。

具体的な設定

Web Caster V120では、IPv6ブリッジ機能を無効にしておきます。これで、IPv6での通信はドコモ光ルーター01側からになります。 f:id:shakemid:20180901133617p:plain

ドコモ光ルーター01は起動時に接続方式を自動判定します。IPoE接続は、手動では設定できないようでした。 f:id:shakemid:20180901133728p:plain

自動判定で何をやっているのかはわかりませんが、おそらく取得したIPv6アドレスのレンジからIPoE接続事業者(VNE)を判定しているのではないかと思います。ぷららの場合は「OCNバーチャルコネクト」と判定されました。再起動を促されるので再起動します。 f:id:shakemid:20180901133742p:plain

再起動すると、動作状態が「OCNバーチャルコネクト」になりました。これで、IPv4 over IPv6が使えるようになっています。 f:id:shakemid:20180901133943p:plain

IPoEの動作確認は↓のサイトを使うと便利です。 ipv6-test.com

まずは、デフォルトゲートウェイをWeb Caster V120側(PPPoE接続)にした場合は以下のようになりました。IPv4アドレスがぷららのものになっているのがわかります。 f:id:shakemid:20180901134238p:plain

続いて、デフォルトゲートウェイをドコモ光ルーター01側(IPoE接続)にした場合は以下のようになりました。IPv4アドレスがOCNのものになっているのがわかります。 f:id:shakemid:20180901135413p:plain

Googleの「インターネット速度テスト」で速度を測ってみました。結果は一目瞭然で、IPoEが圧倒的に速いです。計測したのは土曜日の23時台なので混雑している時間帯だと思います。今はまだ設備が空いているからだとも言えますが、VDSLの限界の100Mbpsに迫る速度が出ていて驚きました。 f:id:shakemid:20180901232323p:plain

というわけで、IPoE接続でIPv4 over IPv6を使いつつ、PPPoE接続も共存させることができました。 しかし、IPoEを巡る状況はずいぶん複雑になってるのですね。一般的なネットワークエンジニアならわかると思いますが、一般的な人にこれを理解してもらうのはかなり難しいように思います。

CISSP受験体験記

CISSPの試験に合格しました。勉強期間は約4週間で、幸い一発合格できました。

CISSPは米国発のセキュリティの認定資格で、国際的に認められています。セキュリティ業界では有名な資格ですが、日本ではCiscoOracleの資格と比べるとあまり知名度はないかもしれません。

試験の内容は、NDAにより一切口外してはいけないことになっているので、勉強方法や受験の流れについて振り返ってみたいと思います。

CISSPを目指す方の一助になれば幸いです。

勉強方法

まず、CISSPの試験はそれなりに難しいです。少なくとも、IPA情報セキュリティスペシャリスト(今は情報処理安全確保支援士というださい名前の試験に変更)と同等かそれ以上の難易度という感想です。 難しいと思った理由は主に3つです。

(1) 範囲がすごく広い

CISSPの試験範囲は8つのドメインに分かれていますが、その1つ1つで本が何冊も書けるんじゃないかというほど広いです。 問題集には、裁判の進め方からNmapコマンドのオプションまで出てきます。全てに精通しているような人は超人だと思います。 私は、IPAネットワークスペシャリスト情報セキュリティスペシャリストを取得していますが、それでもカバーできるドメインはせいぜい3つか4つくらいだと思います。

(2) 問われる内容がそれなりに深い

出題形式はだいたい4択問題なので、IPA情報処理技術者試験の午前問題と似たような感じですが、同等と思うのは甘いです。午後問題程度のそれなりに深い内容を問われると思った方がよいと思います。 出てくる用語もそれなりに難解です。例えば、Certification と Accreditation の違いとか。日本語だと認証と公認という感じで違いがよくわかりませんが、両者は違います。 試験は日本語で受けられますが、外資系ベンダの試験にありがちな感じで、日本語だと意味がわからなかったり、誤訳としか思えないところもあるとかないとか。英語の原文も同じ画面で確認することができるので、英語の原文を必ず確認した方がよいと思いました。

(3) 独特で曖昧な問題が多い

この3つ目が最大の難関だと思います。問題に対する答えを覚えるだけでは全く歯が立たないと思います。 表現するのは難しいですが、自分の主観は捨てて、「CISSPであればそう考えるべきである」というような視点が必要だと思います。 CISSPは、現実的でビジネス(経営者)寄りな視点を求められるので、例えば、リスクマネジメントの目標が問われるような場合は、「リスクを完全に無くす」のではなく「(経営者が)リスクを許容できるレベルにする」のような選択肢がおそらく正解に近いんじゃないかと思います。 これは、問題集をやってみるとわかると思いますが、何を言っているのかさっぱりわからない問題が出てくると思います。私もそうでしたが、「CISSPにあるべき視点」のようなものを意識して、慣れてくるとなんとなく正解が見えてくるようになってきたと思います。

CISSPの一般的な勉強方法として、NRIさんがやってる1週間のセミナーがあります。しかし、私は未受講です。 セミナーの評判は良いのですが、受講に50万円くらいかかるのが大きな障壁です。これを受講するのは会社のサポートがないと厳しいでしょうね。 独学だと知識の偏りが気になるので、合格後でもなんとかして受講したいところです。

CISSP CBKトレーニング | 人材育成・研修 | サービス案内 | 情報セキュリティのNRIセキュア

以下に、私が勉強に用いた教材を紹介していきたいと思います。

CISSP認定試験 公式ガイドブック

CISSP認定試験 公式ガイドブック

数少ない日本語の本です。なんとなく購入していましたが、あまりの厚さに3分の1ほど読んで挫折しました。現在は絶版になっていて、新版が予定されているようですが、紙の本はいらないかなと思います。(売却してしまいました...)

CISSP Official (ISC)2 Practice Tests

CISSP Official (ISC)2 Practice Tests

練習問題が1300問収録された本です。私はKindle版を購入しました。比較的お手頃な価格で非常におすすめです。 この本を購入すると、本と同じ内容のテストがWebで利用できるようになります。Webテストの作りがいいので本を読むことはほとんどなかったです。

ちなみに、Webテストの登録方法は、本のあるページに書いてある内容を入力するというものでした。セキュリティ的には弱いですね :-p

Webテストはこちら https://testbanks.wiley.com/

私はまず、このWebテストで50問ほどのミニテストを作ってなんとなく実力を判定してみました。初見でおおむね7割前後は得点できていたので、苦手なドメインを中心に後述の本を拾い読みして偏りを埋めるという勉強のやり方で進めました。 ネットワークセキュリティや暗号のところは初見で8割くらい得点できましたが、米国の法律や裁判のところはさっぱりわからず、半分くらいしか得点できませんでした。 IPA情報処理技術者試験でも法規の出題はありますが、午前問題でせいぜい数問とかなので、まるごと捨ててもなんとかなりますが、CISSPでは2,3割がそんな感じなので捨てるわけにはいかず苦労しました。考えてもわからない暗記物はかなり苦痛ですが、そういう試験なので仕方ありません。 暗記するしかない問題もありますが、大部分は考えないといけません。問題に対する答えを覚えるのではなく、なぜその答えになるのか、納得できるまで後述の本で該当箇所を勉強するのがよいと思います。

CISSP (ISC)2 Certified Information Systems Security Professional Official Study Guide

CISSP (ISC)2 Certified Information Systems Security Professional Official Study Guide

この本も非常におすすめです。これもKindle版を購入しました。こちらも登録するとWebテスト1421問を利用できるようになります。Webアプリの作りは前述の Practice Test のほうがしっかりしてます。

Webテストはこちら http://sybextestbanks.wiley.com/course/index/id/102

1000ページ以上ある辞書のような本なので、全部読むのは苦しいと思います。気になるところを拾い読みするだけでも充分勉強になると思いました。時間と根性がある人は全部読むととても勉強になると思います。 これももうすぐ新版が出るようです。

これも数少ない日本語の本です。半額になってたのでKindle版を購入してみました。 ちょっと内容が古く、ときどき誤訳じゃないかと思うところがあったりしますが、日本語で概要を捉えるにはよいんじゃないかと思います。章末の問題集が、公式の本よりひねられた感じになっていて、本番の雰囲気に近いような気がしました。

CISSP Study - (ISC)² OFFICIAL

CISSP Study - (ISC)² OFFICIAL

  • learnZapp
  • Education
  • $9.99

前述の Official Study Guide から、Exam Essencials と Review Questions を抜き出したようなアプリです。本があればいらない気はしますが、手軽にテストの練習ができて楽しいので、1200円がそれほど高いと思わなければ買ってもいいと思います。

申し込み~試験

福岡センタでの残念な出来事

2週間くらい勉強して、なんとなく模擬テストで8割くらい得点できていたので、そろそろ行けるかなと思って申し込むことにしました。受験するだけで7万円くらいかかる試験なので相当の覚悟が必要です。 現在のところ、日本では東京・大阪・福岡の3カ所でしか受験することができません。私が申し込もうとしたときには、東京・大阪は1ヶ月以上先までほとんど空いていませんでした。福岡だけはわりと空いていたので、たまには福岡まで旅行するのもいいかなと思って、福岡センタで受験することにしました。試験日は約2週間後にしました。

Pearson (ISC)² 認定試験 https://www.pearsonvue.co.jp/Clients/ISC2.aspx

福岡センタは博多駅の近くにあるので、博多駅の近くで前泊しました。試験開始の30分ほど前に行き、静脈の登録や写真撮影などを行ないました。 CISSPの試験では、途中の休憩は自由で、試験ルームの外に出ることもできます。ただし、休憩中も時間は経過していきます。試験センタに来る前に、飲み物と軽食を買っておくのがよいと思います。

適当に休憩をはさみつつ、250問中150問ほど回答したところで、画面がフリーズしました。システム担当の方が慌てた感じで試験ルームに入ってきて、トラブルシューティングを始めました。どうやら、サーバのトラブルで、部屋にいた全員が影響を受けたようです。部屋には6人くらいいたと思いますが、4人くらいは試験を途中から再開できたようでした。しかし私ともう1人は、途中経過を復元できなくなってしまい、その日はもう再開できないと謝られてしまいました。 ピアソンで何回か別の試験を受けたことはありますが、こんなことは初めてです。思わぬトラブルで試験を中断されて困惑しましたが、こういうトラブルの時のシステム担当の方の気持ちは痛いほどよくわかるので、同情してしまいます。

別の日程での再試験を提案されましたが、私はわざわざ福岡まで来てるのでそれなりに旅費がかかっています。完全に先方の過失なので旅費を補填できないのか交渉しましたが、受験の規定に何が起きても受験料以上は保証できないとの記載があり、聞いてもらえませんでした。 再試験については、たまたま2日後に東京センタの空きができたようなので、東京センタで受験することとなりました。 旅費については無念な気持ちでいっぱいですが気持ちを切り替えるしかありません。わざわざ福岡まで来たのはいったい。博多でラーメンを食べて帰るだけの旅になってしまいました。

東京センタで再試験

東京センタは有楽町と新橋の中間くらいにある、帝国ホテルタワーの18階です。試験は9時からなので、30分くらい前に来て、同じように静脈の登録や写真撮影などを行ないました。

100問毎くらいに休憩を挟みつつ、2時間くらいで250問に回答しました。わからない問題にはマークを付けました。 250問一通り終わった後、50問くらいマークした問題を見直し、さらに250問全てを2回見直しました。 結局マークした50問くらいはよくわかりませんでしたが、合格基準はおおむね70%と言われていて、仮に全部外していても80%くらいは得点できているだろうと判断したので終了しました。 その時点で、3時間10分ほど経過していました。制限時間は6時間なので、時間的にはだいぶ余裕がありました。 朝の9時前から始めて、12時頃には終わっていたのでそれほどお腹も減らず、体力的にも余裕がありました。

試験終了後、結果はすぐにわかります。画面には何も出ませんが、受付で試験結果が紙で出力されます。結果を見ると、無事に合格していました。昔から、いつか取得しようと思っていた資格だったのでうれしかったです。 CISSPの試験では合格すると点数はわかりません。不合格だと弱かったドメインがわかるらしいです。

福岡で150問ほど進んでたので、本番の試験の傾向をなんとなく知ることができ、それを踏まえて余分に1日勉強できたので、再試験の時は気持ちに余裕があったように思います。結果的には良かったんじゃないかなと思いました。 合格してしまえば福岡でのトラブルもレア体験として笑い飛ばせるというものです。

今後の対応

今後は、(ISC)²に登録して正式にCISSPと認定される予定です。CISSPホルダーからの推薦(エンドースメント)が必要なので、知人のCISSPホルダーにお願いしようと思います。 知人にCISSPホルダーがいない場合は(ISC)²が直接認定してくれるようですが、レジュメを提出したりしないといけないようでちょっと面倒かもしれません。

CISSPの試験は、2018/4から大幅に変わるようなので、この記事の内容は古くなる可能性があります。最新の情報は(ISC)²のウェブサイトをご参照ください。

japan.isc2.org

最も大きな変更は、試験の方式がCAT(Computer Adaptive Testing)という方式になるところだと思います。問題数が250問から100問になり、時間も6時間から3時間に短縮されるようです。難易度はおそらく上がるのではないかと思います。 現行の250問の試験では、各ドメインの出題比率が決まっているので、苦手なドメインを得意なドメインである程度カバーできますが、CAT方式だと、おそらく最初に採点に関係ない苦手なドメインを見極めるための問題が出題されて、その後苦手なドメインの問題が重点的に出題されるような形式になるのではないかと思います。 これから受験される方は、苦手なドメインがなくなるよう、より満遍なく学習するようにがんばってください。

CISSPとは編集

  • Certified Information Systems Security Professional (公認情報システムセキュリティプロフェッショナル) CISSP認定資格とは、(ISC)&#178;(International Information Systems Security Certification Consortium)が認定を行っている国際的に認められた.. 続きを読む
  • このキーワードを含むブログを見る

kendama.asia

kendamaドメインを1つくらい取っておいてもいいかなと思ったので、kendama.asia ドメインを取得しました。
とりあえず Kendama Revolutions の転送アドレスとして設定しました。
http://kendama.asia/

kendamaドメインの登録状況をざっと検索してみました。

続きを読む

カスペルスキー

情報セキュリティEXPO@国際展示場に行ってきました。
アンチウイルスソフトカスペルスキーのブースで、開発者でCEOのユージン・カスペルスキーがプレゼンテーションをやってました。パッケージでもおなじみですね。
内容は、サイバー犯罪者同士のビジネスの話や航空機のセキュリティの話などで、ユーモアを交えつつのおもしろいプレゼンテーションでした。
カスペルスキーブースのノベルティグッズは宇宙食のプリンでした。ふつうはボールペンとかメモ用紙とかなのでさっぱり意味がわかりませんがロシア式のジョークでしょうか。食べてみたらちょっと不思議な食感でした。

PostfixのOP25B対策

ここ数日自宅のSMTPサーバからメールが届かないなと思っていたら、最近ISPOP25Bを始めていたのを忘れていました。
しょうがないので、Postfixのドキュメントを参考にホスティングサービスのメールサーバのサブミッションポート宛にSMTP-AUTHありで中継させることにしました。

だいたいこんな感じの設定を行いました。

/etc/postfix/sasl_passwd
-------------------------------
[mail.example.com]:587 username:password
$ postmap hash:/etc/postfix/sasl_passwd
main.cf
-------------------------------
relayhost = [mail.example.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_type = dovecot

設定してみたものの以下のようなログが出て動作しないのでドキュメントをよく見てみると、Dovecot-SASLはサーバ側の認証しか対応してないようです。

warning: unsupported SASL client implementation: dovecot
サポートしているSASLの実装
 * Cyrus SASLバージョン1 (クライアントおよびサーバ)。
 * Cyrus SASLバージョン2 (クライアントおよびサーバ)。
 * Dovecotプロトコルバージョン1 (サーバのみPostfixバージョン2.3以降)

このためにCyrusをインストールするのもめんどくさいなーと思いつつ、とりあえず設定を元に戻しました。
元に戻したつもりだったのですが、このとき、relayhostの設定を残したままにしてしまいました。SMTP-AUTHを行っていないので当然リレーできないはずですが、なぜかリレーできてしまいました。
考えてみると、fetchmailを使って5分ごとにPOP3でメールを取得しているのを思い出しました。今さら使うことはないと思っていましたが、POP before SMTPが有効になっていたんですね。
あまりきれいな解決策ではないですがとりあえずこのままにしておこうかと思います。
そのほかの策としては、

くらいでしょうか。
SPAM対策は必要だと思いますが、なかなかやりにくい時代になってまいりました。

音楽保存サービス:ストレージ利用は著作権侵害 東京地裁

音楽保存サービス:ストレージ利用は著作権侵害 東京地裁−今日の話題:MSN毎日インタラクティブ

記事タイトルを見たとき、不特定のユーザがダウンロード可能なアップロードサービスかと思ったのですが、どうもそうではなく、記事を読む限り、自分でリッピングした音楽データを自分だけがダウンロードできる状態でアップロードできるサービスのようです。
これは暴挙もいいとこでしょう。自分だけがダウンロードできるということは、著作権で認められている私的使用のための複製にあたると思われますので、何を侵害しているのか全く理解できません。著作隣接権公衆送信権送信可能化権は、著作物を「公衆」に向けて送信する権利ですので、自分しかダウンロードできないサービスには適用しようがないように思います。
もしこれがダメなら、Google MailやYahoo!ブリーフケースは確実にアウトでしょう。東京地裁がこんな判例を出したというのはちょっと信じがたいので、何かの間違いだったと思いたいです。

公衆送信権 - Wikipedia