Vmware ESXi でVMホストのディスクが圧迫されてインスタンスが落ちる問題(原因と対策)

背景

バックアップ用DBを作るために、でかいディスクを持つ物理サーバの上にVmware ESXiをたてた。 DBに他のSlaveからデータをscpしてみたら途中で突然インスタンスが落ちた。起動もスナップショットの操作も出来ない状態。 インスタンスへのディスク割り当ては200G。メモリは8G割り当て。 scpしたファイルは40G程度で、開きVMホストの元の空き容量は30G程度だった。

原因

datastoreを更新してみると空きがほぼ0になっていた。 詳細なファイルを見てみると以下のようなファイルが大きかった。(ホスト名を hostnameとする)

  • hostname.vmdk
  • hostname-49271ad6.vswp
    • 8G。メモリオーバーコミットをする設定だと、物理マシンのメモリと直接マッピングされずにインスタンスのメモリはディスクに書かれる見たい。
  • hostname-000001.vmdk, hostname-000002.vmdk
    • 合計で27G
    • 今回の犯人。スナップショットをとった後にインスタンス内で更新があると、その差分を出すためにredoログ(差分)としてここに書かれる。
  • vmware-1.log
    • 合計で数M。今回の問題とは無関係なので略

対策

  • メモリオーバーコミットをさせない。インスタンスのメモリ設定で「すべてのゲストメモリを予約(すべてロック)」設定を入れる。
  • スナップショットを全部消す。そうするとredoログが吐かれないのでVMホストのディスク圧迫が起こらない。

コメント

スナップショットが取れないのは不便だが、物理マシンと同じだと思えばまあよし。 ある程度構築して本番投入するまではスナップショットを使って、ほとんど変更が無くなったらスナップショットを全部消すなどの運用でカバーできそう。

Dockerを立ち上げたいがホストOSのルーティングと衝突して上がらない件

背景

Scientific Linux 7.2 で、Dockerを立ち上げたときにエラーが出て上がらなかった。問題と解決。

エラーメッセージ

# docker daemon --debug 最後の行に以下のもの。

FATA[0001] Error starting daemon: Error initializing network controller: Error creating default "bridge" network: failed to allocate gateway (192.168.17.0): Address already in use

解決方法

(すでに解決して消えてしまったのでうろ覚えだが)もうちょっと前に 192.168.0.0/16のネットワークが割り当てられないみたいなエラーが出ていた。 ホストOSですでにそのネットワークに対してルーティングが入っていてDockerに割り当てることができなかった。Dockerはデフォルトでこのネットワークを使おうとする。指定したければ --bip=CIDR で指定すればよい。

172.16.0.0/12 もホストでルーティング入ってしまっていたが、使わないのでいったん落とす。

# ip route del 172.16.0.0/12 
# docker daemon --debug -s overlay --bip=172.16.1.1/24

Bridge IPを指定してやる。ここで、どうもIPはdocker0というインターフェースに使うようで、それ経由でDocker界に疎通するっぽい。なので、ネットワークアドレスを指定するとこれまた割り当てられないよ!というエラーがでる。 参考までに、docker0インターフェース。

$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.1.1  netmask 255.255.255.0  broadcast 0.0.0.0

RHEL(Scientific Linux)7系でrouting追加ができない件(問題と解決)

背景

殆ど初めてRHEL7系を使った。7系でRouting設定に微妙にはまったのでメモ。

問題

以下のコマンドで追加しようとしたらエラーがでた。

# ip route add 172.16.0.0/12
RTNETLINK answers: No such device

解決

インターフェース名を指定してあげなくちゃダメだった。

# ip route add 172.16.0.0/12 dev eth0

6系のrouteコマンド使った時には適当に疎通できるインターフェースを判別してやってくれた気がするけど。正直大体static-routesファイルや route-eth* に書いてしまってnetwork restartしてたりしたのでどうだったかははっきりしない。

initscriptの記述 LSB記法とchkconfig

背景

kibana をインストールするときに、initscriptを自分で作成した。その時に疑問に思った initscriptの記法についてメモしておく。 https://github.com/akabdog/scripts/blob/master/kibana4_init ここらへんを参考に自分でPATHなど変更して使った。上の方にBEGIN INIT INFOで始まるブロックがあるが、それの意味を調べた。

参考

INIT INFO

LSB(Linux Standard Base)の記法。ディストリビューションによらない共有の記述みたい。chkconfigはRedhat系だけっぽい。

### BEGIN INIT INFO
# Provides:          kibana
# Required-Start:    $local_fs $remote_fs $network
# Should-Start:      $time
# Required-Stop:     $local_fs $remote_fs $network
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: Kibana 4
# Description:       Service controller for Kibana 4
### END INIT INFO
  • Required-Start: ここで指定されたserviceを起動した後でこのinitscriptのプロセスを起動する
  • Default-Start: 起動するrunlevel を指定する。ネットワーク経由でアクセスする前提のプロセスについては大体3(マルチユーザモード)と5(マルチユーザモード+Xディスプレイマネージャ)。2はマルチユーザモードだけどネットワークを起動しない。

chkconfig と書いてあるinitscriptもあるけど?

elasticsearch はLSBの記法に加えて、内容が重複するものが書いてあった。

# chkconfig:   2345 80 20
# description: Starts and stops a single elasticsearch instance on this system
#

### BEGIN INIT INFO
# Provides: Elasticsearch
# Required-Start: $network $named
# Required-Stop: $network $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: This service manages the elasticsearch daemon
# Description: Elasticsearch is a very scalable, schema-free and high-performance search solution supporting multi-tenancy and near realtime search.
### END INIT INFO

chkconfigの記法では、priority が数値で指定できるが、LSBの記法だとRequired-startとかで前後関係しか指定できない。priorityの間に新しいのが入ると大規模な(数値の)シフトがおこるっぽい。 内容が重複しているので、LSBとchkconfigでどちらが優先されるのか調べたところchkconfigコマンドのmanによれば、LSBの記述が優先されるみたい。

読書メモ:達人に学ぶDB設計 徹底指南書

【参考】

達人に学ぶDB設計 徹底指南書 kindleで買って、一旦50%くらいまでさらっと読んだ状態。ざっくりER図がかけて、正規化が何かぼんやりわかるところまで。パフォーマンスチューニングについてはこれから。

【データベース設計】

やること

  • エンティティの抽出( どういう機能を入れたいか、またそれに必要なデータの抽出)
  • エンティティの定義
  • 正規化
  • ER図の作成

エンティティはデータを属性(attribute)という形で保持する。テーブルにおける「列」と同義。 テーブル名は、すべて複数形または複数名詞でかける。原理的に同じ種類のものが複数入っているため。

【テーブルに対する制約】

  • NOTNULL制約:この行は絶対にNULLにならないというのがわかっていればNULL禁止にする。列単位の設定。可能な限り設定したい。
  • 一意制約:ある列の組について一意性を求める。主キーでは当然この制約があるが、ほかの列にも設定可能
  • CHECK制約:列の取りうる値の範囲の制限。数字や文字列をあらかじめ決めておく。

【正規化】

正規化とそれによってつくられる正規形。 第1~第5正規形がある。数値があがると正規化のレベルが上がる。 正規化をするほどデータ整合性は高まるが、検索性能が劣化する。実用レベルでは第3正規形までを考えれば十分。 それぞれの概要

  • 第1:一つのセルには一つの値だけ
  • 第2:テーブル内に部分関数従属があるものを、完全関数従属のみのテーブルを作る。
    • 関数従属性を満たす。X列の値を決めればY列の値が1つに決まる。「会社IDと会社名」、「社員IDと社員名」が同一テーブルにある場合にはそれぞれ部分関数従属。それぞれテーブルを分ければ完全関数従属。これをやるメリット:社員がいるかどうか変わらない会社を登録できない。MULLかダミーの値を突っ込むことになる。独立していれ会社テーブルにだけ登録できる。
  • 第3:2段階の関数従属(推移的関数従属)をなくす。すべてのテーブルについて非キー列がキー列に従属するようにする。

メリットデメリット

  • メリット: 更新のミスを防ぐ。テーブルの持つ意味が明確になる。
  • デメリット:テーブルの数が増えるとSQLで結合が必要になり、パフォーマンスが低下する。

1テーブルには一つのエンティティ情報を含める。正規化の逆操作は結合。

【ER図】

スタンダードなER記は主に二つ。

  • IE(Information Engineering)表記法(通称鳥の足) 
  • IDEFIX

テーブルの表現方法はどちらも同じ。テーブル名、上に主キー、下に非主キー属性のもの。FKにはその旨をかく。外部キー:Foreign key(FK)。主キー:Primary Key(PK)。 テーブル間の関係は、基本的に1:多。多:多の場合には1:多に分解する。 あるテーブルの主キーが他のテーブルに列として含まれているかどうかというのが重要。

IE表記

  • "ー" は相手のエンティティと対応するレコード数が1(カーディナリティが1)。
  • "○" はゼロ、鳥脚は複数。二つ組み合わせて、ゼロ以上の複数を表す。

IDEFIX表記

関連実体

多:多は関連実体で解決する。 学生:講義 とかは多:多になってしまう。二つのテーブルを紐つけようとすると無理やり学生テーブルに「講義コード」列をいれることになる。そうすると講義未登録の学生はNOTNULL制約によりレコード追加できなくなる。 それを防ぐために間に関連実体を挟む。受講エンティティを間に挟んで1:多の関係を二つにする。「学生」「講義」のそれぞれの主キーを組み合わせたキーを主キーとする。

【パフォーマンス劣化を防ぐ】

joinは重い処理。複数(特に3つ以上)を結合すると思い。むしろ非正規化してjoinを使わない方法も。 ただし、非正規化のテーブルに対してUPDATEをかけるとものすごくレコードが多かったりする。正規化されていればテーブル一つにちょっと更新をかければよいことが多い。 データ整合性とパフォーマンスはトレードオフ。原則的には正規化する。非正規化は最後の手段。劇薬。

VagrantのCent6.6 のBoxを使ったらsshできなかった

背景

新しいMacを買って、VirtualBoxVagrantを使ってAnsibleの足場環境を作りたい。CentOSVMを立てようとした。 http://www.vagrantbox.es/ ここから適当なBoxであるCentOS6.6をダウンロードしてきて使おうとしたがエラーが出てうまく vagrant up できないように見えた。

エラーメッセージ

default: Warning: Authentication failure. Retrying...

使おうとしたBox

https://github.com/tommy-muehle/puppet-vagrant-boxes/releases/download/1.0.0/centos-6.6-x86_64.box

問題と解決

vagrant boxはvagrantユーザのパスワードがvagrantになっているっぽいので、それでパスワードログインする。 VM内のauthorized_keysのパーミッションが間違っていて、0664みたいになっていた。これを0600に修正して問題なく vagrant ssh できるようになった。

Rubyのインストール(rbenvを使った方法)

これは何

rubyのインストールの手順をまとめている。

参考

LinuxにRuby on Railsをインストールする | tsuchikazu blog

rbenv を使って ruby をインストールする(CentOS編) - Qiita

手順

rbenvのインストール

まずRuby環境管理ツールのrbenvをインストールする。rbenvは多分ruby environmentの略。 そのためにgitをインストールする。gitはざっくりいうとコード管理ツール

$ sudo yum install -y git
$ git --version
git version 1.7.1

現在のディレクトリにrbenvをダウンロード。ディレクトリはここでは隠しディレクトリ .rbenv とする。

$ git clone git://github.com/sstephenson/rbenv.git ~/.rbenv

# PATH に追加
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile

# .bash_profile に追加
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile

# 上記設定の再読み込み
$ exec $SHELL -l

# インストールの確認
$ rbenv --version

バージョンが表示されればOK。

rbenvのプラグインとしてruby-buildをインストールする。これを使わないとrubyの煩雑なインストールが手作業になるっぽい。ディレクトリは先ほどの.rbenvの下へ。

git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

rubyのインストール

# あらかじめ依存するライブラリopensslを入れておく
$ sudo yum install -y openssl-devel

# インストールできるrubyのリスト見る
$ rbenv install -l

# 今回は2.1.0をいれてみる
$ rbenv install 2.1.0

# 新しいものをインストールした後にはrehashコマンドを用いて適切なディレクトリに配置してもらう
$ rbenv rehash

rehashについてはこちらも参照のこと  rbenv rehashは何をやっているのか? - DQNEO起業日記

インストールには結構時間がかかるので気長に待つ。Ruby関係は概して長い。 トラブルが起こったらエラー出力で指定されているlogファイルを見て、何が足りないのか確認する。

# 今使用できるRubyの情報を見る
$ rbenv versions

# どれを使うか選択する
$ rbenv global 2.1.0

# 今使っているRubyに*がついているはず
$ rbenv versions