最近の変更サイトマップ

FreeBSD 10に入れたTomcat 7のタイムゾーン設定方法

何かの拍子に、Tomcat 7.0で動かしているサービスのタイムゾーンがUTCとして認識されるようになってしまった。マシンのRTCは昔からUTCで、OSのロケール≒タイムゾーンも以前からJSTで特に変更はしてないのだが…。

変わっちゃったもんは仕方ないんで、Tomcatのタイムゾーンを変更する方法を調べたところ、setenv.shでCATALINA_OPTS環境変数を弄ればいいらしい。setenv.shってどこにあんのよっていうと、/usr/local/apache-tomacat-7.0/bin/である。もっとも自分の環境(FreeBSD 10.3-RELEASE-p26/Tomcat 7.0.59)ではsetenv.shは無かったんだけど、startup.shを見るにsetenv.shがあれば読み込むように見えたので、新規で作ったら上手く行った。

setenv.shの中味は以下の通り。

export CATALINA_OPTS='-Duser.timezone=Asia/Tokyo'

あとはApacheとTomcatを再起動してやればおk。

ブリッジネットワーク接続の仮想マシンを使う時はport-securityに気をつける

ブリッジネットワーク接続の仮想マシンがあり、その通信がCiscoのCatalystスイッチを通るネットワーク構成の時は、スイッチのポートセキュリティ設定に気をつけなければならない。さもないと仮想マシンが通信できなくてハマる。VMとLAN内の物理マシンとでARP RequestとReplayは通っており、互いのARPテーブルは正しく作られているように見えるのに通信が出来なくて超ハマる。3ヶ月くらい悩んでた…(ヽ´ω`)

port-securityが有効なポートでは、最初に通過したMACアドレス以外のフレームが破棄される。

ここで、ブリッジ接続の仮想マシンのフレームは、物理マシンが繋がってるポートに流れる事になる。つまり、1ポートに対して複数のMACアドレスが関連付けられるわけだが、port-securityが有効だと最初の通信のMACアドレスしか有効にならない。それは殆どのケースで物理マシンのMACアドレスになるので、VMは一切通信出来なくなるという寸法。逆にいえば、物理マシンの通信ならOKなので、NATでVMの通信を物理マシンの通信に変換してやれば通信できるということだ。実際、NAT接続でなら通信出来てた。

対策方法は次の3つ。

  1. port-securityを無効化する
  2. 信頼するMACアドレスを静的に追加する
  3. 学習するMACエントリの上限を引き上げる(デフォルトでは1個)

自宅ネットワークならport-security無効化が簡単で影響も殆どないかと。

この問題を調べてる時に、ブリッジ接続が上手くいかないと嘆いているロシアのフォーラムを見つけたんだけど、結局使ってるホスティング業者を変えたら動いた!って結末だったので、恐らくダメだった方の業者のスイッチで似たようなセキュリティ設定になってたんだろうと思う。

原因がわかって全てが繋がった感じ。通信だけにね(´・∀・` )

参考サイト

VirtualBox上のWin 7でディスクイメージとzvolの速度比較(ついでにbhyveも)

仮想マシンのストレージ形式について、一般的にはイメージファイルよりもzvolの方が適していると言われている。ホストのファイルシステムレイヤを通過したファイル上にゲストのFSレイヤを通したFSを構築するよりかは、zvol(の薄いレイヤしか通らない)のブロックデバイスをゲストのFSレイヤに渡した方が効率が良さそう、ってのは理屈としても合っている。

以前から実際に速度比較しようと思いつつ、ようやく実行に移せた。環境は以下の通り。

  • ホスト
    • FreeBSD 11.1-RELEASE-p1
    • VirtualBox 5.2.0
      • CPU: Xeon E5-2648Lv3 1.8GHz 12C24T
      • RAM: 64GB
      • SSD: Intel DC S3500 480GB
        • SATA 3接続
        • ZFSのLZ4で透過圧縮している
  • ゲスト
    • Windows 7 Ultimate (x64)
      • CPU: 4コア
      • RAM: 8GB
      • SSD: VirtIO 40GB

ゲストのストレージを、同一内容のイメージファイルとzvolデバイスとで切り替えてCrystalDiskMark 6.0.0で速度を計測した。なお、イメージファイルからzvolへの変換は以下のコマンドで行った。

VBoxManage clonehd /path/to/vms/Windows/HDD.vmdk /path/to/vms/HDD.raw --format RAW
zfs create -V 40G zvm/zvols/Windows
dd if=/path/to/vms/Windows/HDD.raw of=/dev/zvol/zvols/Windows bs=4096
VBoxManage internalcommands createrawvmdk -filename /path/to/vms/Windows/zvol.vmdk -rawdisk /dev/zvol/zvols/Windows

おろ、殆ど変わらんがな…(´・ω・`)。シーケンシャルR/W共にSATA 3の上限ぶっちぎっちゃってるし、ホストのキャッシュが効いちゃってる?

というわけで、VirtualBoxの「ホストのI/Oキャッシュを使う」オプションを切って再計測。

すごく、、、速いです………。こりゃZFSのキャッシュが効いてるなー。確認してみるとARCで4.8GB持ってるしなー。ベンチ中にtopで見てるとARCがもりもり増えてくし。

ついでにイメージファイルをHDDに置いた時のベンチも取ってみた。

うっは2.5インチHDDとは思えぬ速さwwwww

zpool iostatの結果を見るに、ランダムライトはZFS側でまとめられ、ほぼシーケンシャルライトとしてHDDに書き出されているようだ。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      1    922   153K   105M
  mirror    1.33T  1.38T      1    922   153K   105M
    ada3p1      -      -      0    861  25.5K   105M
    ada2p1      -      -      0    875   127K   107M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      2    932   277K   111M
  mirror    1.33T  1.38T      2    932   277K   111M
    ada3p1      -      -      0    919  50.4K   114M
    ada2p1      -      -      1    890   227K   110M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      0    962   102K   119M
  mirror    1.33T  1.38T      0    962   102K   119M
    ada3p1      -      -      0    941   102K   117M
    ada2p1      -      -      0    965      0   120M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.34T  1.38T      1    940   153K   113M
  mirror    1.34T  1.38T      1    940   153K   113M
    ada3p1      -      -      0    918  76.7K   113M
    ada2p1      -      -      0    906  76.7K   112M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

結論としては、イメージファイルでもzvolでも大差なさそう。ストレージ形式の差よりも、ZFSそのものの動作環境やチューニングの差の方が覿面に影響しそう。なので、好きな方を使えばいいんじゃないかな。俺は扱いやすいイメージファイルの方を選ぶんだぜ。

とりあえずZFSパネェ…。


(2017-11-25 追記)

ついでにbhyveでもやってみた。

ストレージは同一SSDだけど、計測環境は新規インストールのWindows 10なので厳密な比較にはならんけど。なお、ストレージはahci-hdで繋いでる。virtio-blkはWindowsでは現状未対応らしい。

ベンチ結果は左から、gzip-5のZFS上のイメージファイル、同zvol、lz4なzvol。

FreeBSD 11で「warning: total configured swap (X pages) exceeds maximum recommended amount (Y pages).」と言われた時の対処法

「対処法」と言いつつ、FreeBSD 11.1-RELEASE-p4で試した限り、なぜか上手く行かないので対処法になってない。折角調べたので参考情報として残しておく…(´・ω…:.;::..

物理メモリ1.5GBのFreeBSD 11.1-RELEASE環境で、16GBのスワップを追加したら以下のメッセージが表示された。

warning: total configured swap (4194304 pages) exceeds maximum recommended amount (2994784 pages)
warning: increase kern.maxswzone or reduce amount of swap.

カーネルが扱えるサイズを超えるスワップを追加すると出るそうで。本事例だと、最大スワップサイズは2994784ページで、1ページ=4KiBなので約11.4GiBとなる。

この値はどこで決まるかと言えば、warningの2つ目で示されているkern.maxswzoneカーネルパラメータである。スワップ管理用メモリの最大バイト数を指定するパラメータで、11.1Rではスワップ約200MiBにつき1MiBが必要とのこと。特に指定しなければ、物理メモリの8倍のスワップを扱うのに十分な容量が確保される。

実際に確保された量は恐らくvm.swzoneパラメータの値。本事例では53904384バイトとなっており、計算するとwarning中の最大スワップサイズと概ね一致する。

というわけで、/boot/loader.confに次の一行を追加してみた。

kern.maxswzone="75464704"

値はまー適当。11.4GiBで53904384バイト必要なんだから、16GBなら1.4倍して一応4KiB単位に揃えた感じ。

これで再起動すればOK!

……のハズだったんだけど、なぜか値が反映されないの(´・ω・`)。kern.maxswzoneには反映されるんだけど、肝心のvm.swzoneが変わってない。警告も相変わらず出る。kern.maxswzoneは名前の通り最大値を制限するものであって、スワップの最大サイズは物理メモリの8倍という制限は超えられないって事なのかしら…?これ以上はソース見ないとわからんな。

参考サイト

ZFSで使ったことがあるHDD/SSDを再利用する時はzpool labelclearすべき

一度でもZFSで使ったことがあるストレージを別のzpoolに使い回す際は、zpool labelclearコマンドで当該デバイスからZFSラベル情報を消した方が良さそうだ。

再利用デバイスで新しいプールを作ろうとすると、殆どの場合は以下のようなエラーが出て作ることができない。

# zpool create ztank da0p3
invalid vdev specification
use '-f' to override the following errors:
/dev/da0p3 is part of potentially active pool 'zroot'

「有効なプールzrootの一部かもよ」とZFS先生は仰ってるものの、zrootは間違いなくdestroy済みで、僕は確信を以てda0p3でztankを作りたいのだよ。先生ったらお節介~。destroyしたんだからラベル情報も一緒に消しとけよ!と思わなくもないが、ZFSではdestroyの取り消しをサポートしてたりする関係で、こういう仕様なのだろう。削除済みプールの復元については、zpool importの-Dオプションを調べておくんなまし。

ところがである、条件は不明だが、このお節介が働かず以前のラベル情報を残したまま新プールが作れちゃうことがある。こうなるとマジで大惨事。新しいプールと昔のプールが管理情報の上では存在する事になり、見るからにヤバげな状態となる。その時の再現ログが↓これ。

# zpool status
  pool: newtank
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        newtank     ONLINE       0     0     0
          da0p3     ONLINE       0     0     0

errors: No known data errors

  pool: oldtank
 state: UNAVAIL
  scan: none requested
config:

        NAME                      STATE     READ WRITE CKSUM
        oldtank                   UNAVAIL      0     0     0
          1234567890123456789     UNAVAIL      0     0     0

errors: No known data errors

ログ上からは、別々のストレージで構成される2つのプール、newtankとoldtankがあるようにしか見えない。しかし実際のところ、oldtankはnewtank以前にda0p3で使っていたもので、既にdestroy済みのプールなのである。newtankとして実際にデータが書き込まれ、意味消失してるハズの削除済みプールoldtankが認識されているのだ…!

こうなると最早手遅れ。oldtankを再度destroyしようにも「そんなプールは存在しない」と言われるし、ならばとデバイス1234567890123456789をどうにかする方向で頑張ってもどうにもならず…。かと言って、この段階でlabelclearは絶対にしてはいけない。newtankもろとも消えてしまうので_:(´ཀ`」∠):_(実体験)。

というわけで、ZFSプールを作る時は忘れずにlabelclearで以前の情報を消すようにしたい。


(2017-11-14 追記)

タイミングよく本症状が発生したのでスクショをうp。

やった事はと言うと…

  1. 以前のzroot(赤い方)を削除しlabelclear
  2. 新しいzroot(緑の方)を作成
  3. FreeBSD 11.0-RELEASEをインストール
  4. freebsd-updateで11.1-RELEASEに更新するも、ブート時のTrying to mount root~で失敗して起動しなくなる
    • 今にして思えば、この時点で古いプールが認識されて旧zrootの方をマウントしようとしてたのかも…?
  5. kernel.oldの方から起動してfreebsd-updateで11.0の最新にしようとする
  6. 見事に失敗して起動しなくなる。起動スプラッシュのシェルでload kernelもload zfsも失敗する状態。
  7. インストーラメディアから起動してzpool importしたらこの状態

確かにlabelclearしたハズなんだけどなぁ…。変なzpool.cacheでも食ってんのかなぁ…?わからん。


(2017-11-16 追記)

あ、ありのまま起こったことを(ry。

症状が出たHDDの各パーティションを再度labelclearしてddでゼロフィルまでしたにもかかわらず、古い方のzrootが認識されやがったぜ……。最終的にzpool labelclear da0してようやく認識されなくなった。(が、当然GPTは壊れる。セカンダリテーブルは生きてるからパーティションの認識と復旧は可能だが…。)GPTの領域にZFSラベルが書き込まれそうな使い方─つまりディスク全体をzpoolにするような使い方はした記憶がないんだが、どうしてこうなった……?

結論としては、zpoolを作る時は対象デバイスの/dev/daX/dev/daXpYを全てlabelclearするのが安全、可能なら全体をゼロフィルするということで。

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0