最近LDAPのサーバでnetstatを叩いたらなんとセッション数が1000を超えていた。

そんな大規模システムでもないのに何故？？
確かにクライアント側では諸事情でnscdは動かしていないがいくらなんでも多過ぎじゃ？？

ありえないセッション数に調査を開始。

サーバ上でtcpdumpを叩いてLDAPの通信を眺めていると、どうやらwebサーバのhttpd、
mailサーバのsmtpd、さらにはcrondまでもがLDAPサーバにユーザ問合せに来ている。

OSのアカウントしかLDAP認証に対応させていないのに何故だ！？

通信に来るタイミングを見ていると、どうやら親プロセスが子プロセスをfork()する度に、
立ち上げユーザの情報取得の為にnss_ldapライブラリが通信に来てやがりました。

で、ここでさらに疑問が発生。

上記の問題のデーモンの立ち上げユーザは全てroot、もしくは専用ユーザとなっていて
それらはLDAPに入れていない。nsswitch.confではローカルアカウントを先に見に行く
ようにしているのでローカルでアカウントが見つかればLDAPサーバに問合せに来ないはず。

nsswitch.conf

passwd: files ldap
shadow: files ldap
group: files ldap

ローカルにアカウントがあるのに、サーバにも問い合わせが来る原因はnss_ldapっぽい。
こいつが使用されるようになるとget()系のコールの一部がnss_ldapにリンカされてしまい、
それらが呼び出される度にnss_ldapが動き出してサーバへ問合せに来てしまうのだ。

では回避策は？
nss_ldapは/etc/ldap.confを見ているのでldap.confで対応出来ないか？
と思い調べたらあっさり発見。予想通りldap.confで回避可能だった。

以下のパラメータにLDAPに問合せに来て欲しくないユーザを列挙すればいいだけ。
ちなみにこのパラメータ自体デフォルトでは存在していないので追記しました。

/etc/ldap.conf

nss_initgroups_ignoreusers root,・・・,・・・

再びサーバ上でtcpdump。
あれだけ溢れていたLDAPの通信が全く来なくなりました。
(もちろんLDAPに対応させたユーザの問い合わせは普通に来ます)

セッション数も激減。

以上で一件落着。

LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。

前回のLDAPセッション数の問題ついでに。

セッション数といってもサーバ側はリッスンソケットを生成するだけなので、
扱いはローカルのファイルと同じ。つまりファイルディスクリプタによる訳です。

一プロセス辺りのファイルディスクプリタの限界はulimitのopen filesによるので、
ulimitを使えば簡単に変更可能。

デフォルトは1024だった。
(前回はセッション数1000を超えていたのでかなり危険な状態でした。。)

サービス毎にulimitiの値を指定するにはinitスクリプトに以下を追記するだけ。
例えば、LDAP(slpad)のulimitの値を変えるには以下のようにする。

/etc/init.d/slapd

ulimit -Sn 8192 ←ソフトリミットを8192に変更
ulimit -Hn 8192 ←ハードリミットを8192に変更

これでセッション数が1000を超えても全然大丈夫。
(もちろん物理リソースの許す限り)

ついでにOS全体の扱えるファイルディスクリプタを変更するにはカーネルパラメータで。

sysctl -w fs.file-max=xxxxxx ←システム全体で使えるファイルディスクリプタ上限
sysctl -w kernel.threads-max=xxxxxx ←システム全体で使えるスレッド上限(ついで)

以上。

Linuxシステムプログラミング (2008/04/16) Robert Loveロバート ラブ 商品詳細を見る Linuxの概要、カーネル、Cライブラリ、Cコンパイラの基礎知識から、ファイルI/O、バッファサイズ管理、メモリマッピング、システムコール、メモリ管理等実践的なトピックが多く盛り込まれている。

Windowsサービスの依存関係の設定はレジストリで簡単に出来る。

まずはregeditでレジストリエディタを開く。
念のためエクスポートしてバックアップ。

次に依存関係の対象にしたいサービスを下記のキーで開く。
(遅らせたいサービスを選択すること！！)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\サービス名

「DependOnService」のキーが存在していない場合はREG_MULTI_SZタイプで作成
「DependOnService」のキーを開き、「値のデータ」に先に起動したいサービス名を入力

以上。非常に簡単。

HP-UX 11i上でLVMを作成する手順を纏めます。

まず、ioscanで作成対象のデバイスファイルを調べます。

# ioscan -fnC disk

--------------------------------------------------------------------------------------
Class I H/W Path Driver S/W State H/W Type Description
================================================
disk 4 0/2/1/0/4/0.1.6.0.0.0.1 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c4t0d1 /dev/rdsk/c4t0d1
disk 6 0/2/1/0/4/0.1.6.0.0.0.2 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c4t0d2 /dev/rdsk/c4t0d2
disk 8 0/2/1/0/4/0.1.6.0.0.0.3 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c4t0d3 /dev/rdsk/c4t0d3
disk 10 0/2/1/0/4/0.1.6.0.0.0.4 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c4t0d4 /dev/rdsk/c4t0d4
disk 3 0/2/1/0/4/0.1.7.0.0.0.1 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1
disk 5 0/2/1/0/4/0.1.7.0.0.0.2 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c6t0d2 /dev/rdsk/c6t0d2
disk 7 0/2/1/0/4/0.1.7.0.0.0.3 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c6t0d3 /dev/rdsk/c6t0d3
disk 9 0/2/1/0/4/0.1.7.0.0.0.4 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c6t0d4 /dev/rdsk/c6t0d4
disk 12 0/4/1/0/4/0.2.6.0.0.0.1 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c8t0d1 /dev/rdsk/c8t0d1
disk 14 0/4/1/0/4/0.2.6.0.0.0.2 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c8t0d2 /dev/rdsk/c8t0d2
disk 16 0/4/1/0/4/0.2.6.0.0.0.3 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c8t0d3 /dev/rdsk/c8t0d3
disk 18 0/4/1/0/4/0.2.6.0.0.0.4 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c8t0d4 /dev/rdsk/c8t0d4
disk 11 0/4/1/0/4/0.2.7.0.0.0.1 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c10t0d1 /dev/rdsk/c10t0d1
disk 13 0/4/1/0/4/0.2.7.0.0.0.2 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c10t0d2 /dev/rdsk/c10t0d2
disk 15 0/4/1/0/4/0.2.7.0.0.0.3 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c10t0d3 /dev/rdsk/c10t0d3
disk 17 0/4/1/0/4/0.2.7.0.0.0.4 sdisk CLAIMED DEVICE HP HSV200
/dev/dsk/c10t0d4 /dev/rdsk/c10t0d4
--------------------------------------------------------------------------------------

ずらずら表示されましたが今回は"/dev/rdsk/c4t0d1"上に作りたいと思います。
ちなみにこれらはFC経由の外付けディスクです。
(ioscan結果の内蔵ディスクの表示は省きました)

それではpvの作成から。

# pvcreate /dev/rdsk/c4t0d1

------------------------------------------------------------------------------------
Physical volume "/dev/rdsk/c4t0d1" has been successfully created.
------------------------------------------------------------------------------------

次にvgの作成ですが、その前にディレクトリとデバイスファイルを作成しておきます。

# mkdir /dev/vg10
# chmod 777 /dev/vg10
# mknod /dev/vg10/group c 64 0x0a0000

ちなみにmknodのオプションは、"c"でキャラクタスペシャルファイルを作成、
メジャー番号を64、最後にマイナー番号を指定しています。

で、vgcreate。

# vgcreate -e 65535 -s 16 /dev/vg10 /dev/dsk/c4t0d1

--------------------------------------------------------------------------
Volume group "/dev/vg10" has been successfully created.
Volume Group configuration for /dev/vg10 has been saved in /etc/lvmconf/vg10.conf
--------------------------------------------------------------------------

"-e"でpv内のエクステント数の最大値の変更と、
"-s"でエクステントサイズを変更してます。

この後lvの作成なのですが、ディスクが余ってるので
Alternate Linkとしてvgに追加する事にしました。

# vgextend /dev/vg10 /dev/dsk/c10t0d1 /dev/dsk/c8t0d1 /dev/dsk/c6t0d1

--------------------------------------------------------------------------
Volume group "/dev/vg10" has been successfully extended.
Volume Group configuration for /dev/vg10 has been saved in /etc/lvmconf/vg10.conf
--------------------------------------------------------------------------

vg10に"c10t0d1"と"c8t0d1"と"c6t0d1"を追加しました。

ではlvを作成しましょう。

# lvcreate -l 19197 /dev/vg10

-------------------------------------------------------------------------------------
Logical volume "/dev/vg10/lvol1" has been successfully created with
character device "/dev/vg10/rlvol1".
Logical volume "/dev/vg10/lvol1" has been successfully extended.
Volume Group configuration for /dev/vg10 has been saved in /etc/lvmconf/vg10.conf
-------------------------------------------------------------------------------------

オプション"-l"によってエクステント数を指定しています。
先程エクステントのサイズを16(MB)に変更しましたので、
19197×16(MB)で、lvのサイズはおよそ300GBという事になります。

最後にファイルシステムを作成して完了。

# newfs -F vxfs -o largefiles /dev/vg10/rlvol1

----------------------------------------------------------------------------------------------
version 5 layout
314523648 sectors, 314523648 blocks of size 1024, log size 16384 blocks
unlimited inodes, largefiles supported
314523648 data blocks, 314428008 free data blocks
9599 allocation units of 32768 blocks, 32768 data blocks
last allocation unit has 16384 data blocks
----------------------------------------------------------------------------------------------

ちなみにファイルシステムの作成時には"lvol"ではなく"rlvol"の指定になります。

このシステムは共有ディスクタイプのクラスタなので、副系にもLVMの情報が必要です。
なので、LVMの情報を正系からエクスポートして副系にインポートする手順も纏めます。

まず、先程作成したvgをディアクティベートします。

# vgchange -a n /dev/vg10

--------------------------------------------------------------------------
Volume group "/dev/vg10" has been successfully changed.
--------------------------------------------------------------------------

それからvgexportの実行。

# vgexport -p -s -m vg.map.01.081209 -f vg.out.01.081209 /dev/vg10

オプションは"-m"でマップファイルの指定、"-f"でパスのセットを書くファイルを指定、
"-s"と"-p"は共有型のクラスタの場合に、副系でインポートする時に便利なオプションです。

作成されたvg.mapとvg.outを副系にコピーしておきます。

ここからは副系での作業になります。
まずは正系と同じようにデバイスファイルの作成をしておきます。

# mkdir /dev/vg10
# chmod 777 /dev/vg10
# mknod /dev/vg10/group c 64 0x0a0000

次に、vgimportコマンドの実行。

# vgimport -m vg.map.01.081209 -f vg.out.081209 /dev/vg10

----------------------------------------------------------------------------------------------
vgimport: Warning: Volume Group belongs to different CPU ID.
Can not determine if Volume Group is in use on another system. Continuing.
vgimport: Warning: Volume Group contains "1" PVs, "4" specified. Continuing.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.
----------------------------------------------------------------------------------------------

いくつか警告が表示されていますが、
これはexportしたマシンとimportしたマシンが違う場合に表示される警告、
VG上に4つのPVがあるにも関わらず、1つのPVしかしてされてない警告、
バックアップコンフィグが存在していない旨を通知する警告になります。
ちなみに全て問題ない警告です。

最後に、副系でアクティベートしてバックアップコンフィグを取得しておきましょう。

# vgchange -a y /dev/vg10

-------------------------------------------------------------------------
Activated volume group
Volume group "/dev/vg14" has been successfully changed.
-------------------------------------------------------------------------

# vgcfgbackup /dev/vg10

-------------------------------------------------------------------------
Volume Group configuration for /dev/vg10 has been saved in /etc/lvmconf/vg10.conf
-------------------------------------------------------------------------

以上で、LVMの作成と共有化が完了です。

HP‐UX 11iシステム管理 (Hewlett‐Packard Professional Books) (2001/05) マーティ ポニャトスキー 商品詳細を見る HP-UXのシステム管理者向けです。 ブート時の流れや特徴についてよく纏まっています。但し、そうとう厚いです。

ストレージ上に新規のLUNを作成した場合、
通常のサーバだとそれを認識させるにの再起動が発生する。

しかしESXの場合はオンラインのままそれが出来るのである。

やり方はいたって簡単で、新規のLUNをストレージに作成し、
ゾーンやマスキングの設定が全て終了したらVIClientでVCに接続する。

認識させたいESXサーバを選択し、「Configration」タブから「Storage Adapters」を選択。
「Rescan」というリンクが存在しているのでそれを選択。

すると、下記のようなポップアップが表示されるので、
「Scan for New Storage Devices」にチェックを入れてOK。



これだけで新規のLUNをESXが認識出来る。

ちなみに、「Rescan」にはバグがあり、「Storage Devices」と「VMFS Volumes」の両方に
チェックを入れて実行すると、VIClientとESXのバージョンの組み合わせによってはESXが
フリーズしてしまう。

ESXがフリーズすれば当然その上で稼動している仮想OSも全てフリーズ状態になるので、
かなりクリティカルなバグです。

片方づつRescanを実行するか、もしくはバグフィックスのパッチがvmwareから
出てるのでそれを適用してから実行するかなどした方が良いと思います。

ちなみに検証してみた所、VIClient2.0とESX3.0の組み合わせでは現象が発現し、
最新のVIClient2.5とESX3.5の組み合わせでは発現しませんでした。

前者のバージョンをお使いの方はくれぐれもご注意を。

今回はVMware ESX 3.x系のお話。

ESXは物理リソースを仮想マシン同士で共有しているのだが、
メモリのアロケートやCPUコアの割当ては基本ESX任せである。

個別に固定的に割当ても可能だが、それではサーバのアイドル時に他のピークサーバに
対して動的に割当てを変更したりは出来ないので、そういう運用はあまりされていないはず。
そもそもこの運用では仮想化のメリットも半減だと思う。

なので基本はESXにお任せで動的にリソースを割当ててもらうのがベスト。
但し、実は落とし穴もあってそれがメモリバルーニングという機能である。

こいつはメモリ割当てが多いにも関わらず、アイドルメモリの量が多い仮想サーバから
メモリを解放して、忙しく動いているサーバに対してメモリを割当ててやる機能だ。
(厳密に言えば解放までがバルーニングで後の割当てはESXが行う)

この機能自体はサーバのリソースの最適化という意味で有難いのだが、
サーバで稼動してるアプリによっては予めメモリを確保しておくというものも多々ある。

アプリが予め確保しておいたメモリは、消費リソースのピークを想定したはずのものだから、
こいつが奪われるとサービスに影響をきたす恐れがある。

ちなみに検証してみた結果、サービスに影響があるどころかOOMKillerで
そのサービスのプロセスがkillされてしまった。。

例えば仮想マシンに割り当てたメモリが3GB、アプリが予め1.5GBの確保を行う場合、
ESXは物理リソースに余裕があれば最低でも1.5GB以上はこの仮想サーバに割当てを行う。

しかし、他の仮想サーバで負荷が高まって物理リソースに余裕がなくなると、
ESXはバルーニング対象を探し始める。そしてこの時、上記の仮想マシンは
アイドル時だったとすると、格好のバルーニング対象となるのである。そして、
「メモリ大量に割りあっててあげてるのに暇してるね、じゃあメモリいらないよね」
と言わんばかりにESXはバルーニングを発動しメモリを奪っていくのである。

奪われた仮想サーバは予め1.5GBが必用なアプリが稼働中にも関わらず、
メモリを大量に奪われると当然仮想OSからみてもメモリが足りない。

そこで仮想OS自身がOOMKillerを発動し、アプリをkillしてしまうのだ。

これではさすがに困るので回避策として、メモリのリザベーションがある。

これはVirtualCenter上で設定可能なメモリの予約値で、
要はこいつで設定した値はメモリの最低保障値である。

上記の環境に対してリザベーションを1.5GBに設定してあげると、
バルーニングが発動しても1.5GBは残してくれるのである。

また、もう一つ対策方法があり、それはバルーニングによって解放される量を
制限してやる事だ。特定の仮想マシンにsched.mem.maxmemctlパラメータを
メガバイト単位で指定してやればよい。

WebLogicやOracleなど、サービス起動時にメモリを大量に割り当てる
必用があるアプリを仮想マシンで動かす場合は注意が必要である。

今回のお話は以上。

前回に引き続きESXのお話。

仮想マシンを作成しPowerOnすると、LUN上に仮想ディスクのvmdkファイル以外に
vswapという巨大な物理ファイルが作成される。これは仮想マシンに割り当てたメモリと
同じだけ領域が取られので、仮に仮想ディスクを10GB、仮想マシンのメモリを4GB割当て
たと仮定すると合計14GBの領域がLUN上に必要になる。

なのでLUNを作成する時には予めvswap領域も計算して空き領域を確保しておかないと、
仮想マシンのPowerOnが出来ない。vswapは仮想マシン起動時に作成されるが、こいつが
作れないと起動にこけるからである。
(ちなみにPowerOffのステータスだとこのvswapのファイルは作成されない)

ではこいつはそもそも何の為に必用なのか？
ここでまた前回お話したメモリバルーニングという言葉が出てくる。

バルーニングとは、ある仮想マシンからメモリを強制的に解放する機能なのだが、
実際は仮想マシンに上にインストールされているvmmemctlというドライバが行っている。

但し、以下の理由でvmmemctlが使用できない場合このvswap領域にスワッピングされる。

・vmmemctlドライバが未インストール
・vmmemctlドライバが無効にされている
・vmmemctlドライバがOSのブート中などで実行されていない
・vmmemctlドライバが仮想OS自体の負荷などですばやくメモリを解放してくれない

スワップは性能的によろしくないので、普段はバルーニングが優先して行われる。
しかし上記の理由などでバルーニングが出来ない場合には、確実にメモリの解放を行う為
スワップが使用されるのである。その為、割当てメモリと同サイズの領域が必要らしい。

ちなみにデフォルトではvswapは仮想ディスクと同LUN領域に作成されるが、
sched.swap.dirパラメータで変更は可能である。

今回のお話は以上。

前回に引き続きVMのお話です。
今回はvcbMounterについて纏めてみます。

VMware Consolidated Backupをインストールすると、
vcbMounterというコマンドが使えるようになります。

これは仮想マシンをPowerOn状態のままイメージバックアップが出来るツールです。
つまり、サービスに影響を与える事なくOSのイメージバックアップが出来るわけです。
ちなみに仮想OSがWindowsであればファイル単位のバックアップも可能です。

ちょこっと仕組みを纏めておきます。

コマンドを実行すると、対象仮想マシンのスナップショットが作成されます。
それによって仮想マシン(vmdkファイル)に対するwrite I/Oが停止され、
書き込みは全てバッファ上で処理するようになります。

スナップショットが作成されたら(ほとんど一瞬で終ります)、
バックアップ対象のvmdkファイルがバックアップサーバにマウントされます。
(ちなみにバックアップサーバはバックアッププロキシサーバと呼ばれます)

で後はファイルをコピーすればOK。

最後にマウントを解除すれば終わりです。

Consolidated Backupを使用できる前提として以下の条件があります。

1. vcbMounterを実行するOSがWindows2003であること
2. SAN経由でバックアップ対象VMFSのLUNが見えること
3. LAN経由でESXやVCと通信できること

などがあります。

では実際にやってみましょう。

まずインストールですが、VCサーバがwin2003なのでそこにインストールします。
ウィザード形式なのでそのままデフォルトで入れてしまって構わないでしょう。

では実際にバックアップ。
vcbMounterは以下のパスにあります。

C:\Program Files\VMware\VMware Consolidated Backup\Framework>

vcbMounter.exe -h VC -u administrator -p xxxxx -a ipaddr:仮想マシン名
-r e:\mnt\仮想マシン名 -t fullvm -m san -M 1 -F 1

こんな感じ。オプションの説明は以下。

-h　　　ホスト名(VirtualCenterの)
-u　　　実行ユーザ名
-p　　　パスワード
-a　　　バックアップ対象の指定
-r　　 　マウントポイント
-t　　 　バックアップ
-m　 　 実行環境
-M 1　 vmdkファイルを分割しない
-F 1　　vmdkファイルを圧縮しない

これで、VCサーバ上の"e:\mnt\仮想マシン名"へvmdkファイルがマウントされる。
(バックアップ対象の指定は名前解決可能であればホスト名、そうでなければIPでOK。)

ちなみにデフォルトではバックアップされたvmdkは圧縮され、2GB毎に分割される。
なので"-M 1"と"-F 1"で分割も圧縮もせずにそのままマウントしてみた。

後は普通のファイルと同じようにマウントされたフォルダ毎コピーしてあげればOK。

コピーが終了したら、以下のコマンドを実行してアンマウントしておく。

vcbMounter.exe -h VC -u administrator -p xxxxx -U e:\mnt\仮想マシン名

以上でバックアップの完了です。

では、次にリストアについてです。
リストアについては二段階の手順を踏みます。

まず、バックアップしたフォルダ毎、リストア対象のESXへコピーします。
コピー先は/tmpなどで構わないでしょう。

その後、ESX上でvcbRestoreというコマンドを実行します。

こんな感じ。

vcbRestore -h VC -u xxxx -p xxxx -s /tmp/バックアップフォルダ/ -b overwrite

-h　　　ホスト名(VirtualCenterの)
-u　　　実行ユーザ名
-p　　　パスワード
-s　　　バックアップフォルダの指定
-b overwrite

基本的にリストアなので、同一のVMFSフォルダパスに戻されます。
なので"- overwrite"で上書き処理の指定をしてます。

違うフォルダパスに戻す時はcatalogファイルの編集が必要です。
catalogファイルはvcbMounter実行時に作成されますので、
バックアップフォルダの中に存在しています。

catalogファイルの編集が必要な項目は以下の通り。

1. データストアの変更
　　disk.scsi*.diskname
　　config.vmx
　　config.suspenddir
　　config.logdir
2. フォルダパスの変更
3. リソースプールの変更(使用していれば)

1.についてはVI Client内のデータストアブラウザから一覧を取得できます。
ちなみに構文は[datastore_nme] となります。
取得した値を上記パラメータ全てに設定してみてください。

2.3についてはvcbUtilというコマンドを使用して、有効な値一覧を取得できます。
但し、vcbUtilについては/etc/vmware/backuptools.confを使用しますので、
こちらの設定ファイルがきちんと設定されていないと正常に動作しません。
(といっても設定するのはVCサーバ、ユーザ、パスワードくらいで動くはず)

2.については

# vcbUtil -c vmfolders

3.については

# vcbutil -c resourcepools

で値が取得可能です。

取得した値をそれぞれのパラメータにセットすればOKです。

以上でバックアップ&リストアが可能になります。

ちょっとだけ補足：

vcbMounterはESXにも存在しているコマンドなので、わざわざConsolidated Backupを
インストールしたサーバを用意しなくてもESX上でそのまま動かせばバックアップ取れます。

ちょっとした検証でコンピューター名を二つ付ける必用があったので手順の覚え書き。

レジストリエディタを開き、下記のキーを選択。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\lanmanserver\parameters

上記キーに「複数行文字列値」で「OptionalNames」というキーを追加する。
「OptionalNames」の「値のデータ」に別のコンピュータ名を入力すればOK。

後は再起動して、下記のコマンドで確認。

# nbtstat -n

ちなみに元の環境に戻すにはキーを削除すればよいです。

以上。

Linux関連トピック中心のブログにするつもりでしたが
気付いたらあんまりLinux関連の記事をUPしてませんでした。。

なので今日は珍しくLinuxの話題を一つ。

karnel 2.6.19からリリースされているext4ですが、
世間一般にはあまり浸透してないようですね。

(ext4が既にリリースされている事を知っている人自体私の周りでもあまりいませんでした。。)

かくいう私も一度だけ話題作りの検証をしてみただけです。

検証したのが結構前で情報も乏しかったので今回は
とりあえずext4の特徴について纏めてみたいと思います。

まず初めにですが、ext4は今も開発中ですので機能リストは常に流動的です。
正確に把握しておきたいのであればsourceを読むかkarnel watchしておいて下さい。

今回は現時点の最新stable版2.6.28を中心に特徴を纏めます。

1. 16TB越ファイルシステムの利用(e2fsprogsではまだ未サポート)
　　1EB(100万TB)まで利用可能らしい、誰が使うんでしょうかと言いたくなる数字です。
　　ただ大規模なディスクアレイを組むシステムには(将来的にも)有用かも知れませんね。
　　ちなみに現行主流であるext3は最大約8TB(or16TB)です。

2. メタデータのオーバヘッドを減らすエクステントフォーマット
　　ext3ではブロックアルゴリズムで4Kbytesなどの単位(ブロック)に分けてディスク領域を
　　管理しています。ブロックアルゴリズムではディスク上の実アドレスを特定する時サイズが
　　小さめであれば直接参照できますが、サイズが大きくなると間接ブロックなるものを使用して
　　間接参照しなければいけません。間接ブロックは使用するブロック数を減らせるのでそういう
　　意味では非常に有難いのですが、直接参照と比べるとデータブロックへのアクセス回数も
　　増えますのでパフォーマンスが低下します。さらに、サイズが大きくなるにつれ、一段間接、
　　二段間接と多段になっていきますのでよりパフォーマンスが悪化します。
　　そこで、ext4では「エクステント」方式を採用しています。
　　エクステントとは、連続したブロック領域には一つのアドレス(開始アドレス)だけをサイズ、
　　オフセットなどと一緒に論理セットとして渡してあげアドレッシングを効率化する方式です。
　　ファイルサイズの大きいファイルの削除時などはこれによって削除時間が短縮できます。
　　その他にもfsckの時間が短くなるといった利点もあります。

3. ファイル割り当ての改善 (複数ブロックアロケーション)
　　ext3では連続データを書き込む時に都度空きブロックを探して割り当てていました。
　　しかしext4ではブロックアロケーター自身が書込みデータ量に応じて必要となる合計
　　ブロック数を認識し、単一コールで複数ブロックを一気に割り当てる事が可能になりました。
　　これにより、ブロックアロケートによるオーバヘッドを緩和する事が出来ます。

4. 32000 のサブディレクトリ数制限の撤廃
　　ext3では32000までとサブディレクトリの制限がありましたが、ext4では撤廃されました。

5. mtime, atime, ctime, create time(作成時刻) に nsec 単位のタイムスタンプ
　　ext3やたいていファイルシステムでは秒単位のタイムスタンプですが、
　　ext4ではナノ秒単位まで拡張します。

6. ディスク上での inode バージョンフィールド (NFSv4、Lustre)
　　これらのファイルシステムで利用される64bitのバージョン番号が導入されました。

7. uninit_bg 機能による e2fsck 時間の削減
　　ファイルシステム作成時に全てのグループを初期化しないので、
　　ファイルシステム作成時間が短くなります。
　　また、未初期化(未使用)部分はfsck時にスキップされるので、fsckの時間も短縮されます。

8. 頑健さと性能を向上させるジャーナルチェックサム機能
　　ジャーナルデータにチェックサム機構を取り入れました。
　　これにより信頼性とパフォーマンスが向上します。

9. 永続的事前割り当て(ストリーミングメディアやデータベース向け)
　　実際の動作前に、予めアプリケーションが使用予定の領域を確保する場合、
　　ほとんどのファイルシステムは確保済みだが未使用の領域には0を書き込みます。
　　ext4はこの方法を使わず一括してディスク割当てが行われるので、フラグメンテーション
　　を抑えられる。一部のデータベースやストリーミングではパフォーマンスが向上する。

10. 巨大ファイルのサポート
　　ext3では2TBであった最大ファイルサイズが、ext4では16TBになりました。

11. 遅延割当て
　　ext3では、データがバッファに書き込まれる際にディスク空間(ブロック)の割当てが
　　行われていました。これに対してext4ではバッファからディスクに書き込まれる際に
　　割当てが行われるようになったので、ディスク上でより連続した領域への保存が出来ます。
　　また、短期間やテンポラリなファイルは物理ディスク空間が割り当てられる前に消去される
　　可能性もあるので、パフォーマンスも向上します。

ざっとあげてみました。
この他にもflex_bgといった機能や将来的には
オンラインデフラグツールなんかもあるよとのことです。
(オンラインデフラグツールは実際にはもうありますがテストなどが充分ではないようです)

興味がある方は是非kernel sourceを読んで見てください。

詳解 Linuxカーネル 第3版 (2007/02/26) Daniel P. BovetMarco Cesati 商品詳細を見る メモリ管理とプロセス・スケジューリングの項が増補されている。プロセス管理、ファイルシステム、メモリ管理、割り込みハンドラ、同期などソースを交えて説明があるので結構分かりやすい。