2009年11月30日月曜日

Hyper-V上のCentOSで再構築したカーネルがパニックで止まる

Hyper-V上のLinux(CentOS5.4)をいじり始めているのだが、時計がいちいち早いのが多少なりとも気に食わない。
ということで、有効そうな手段の一つである、カーネルのタイマー割りこみタイミングを1000HZ⇒100HZにしたいと思って再構築をすることにした。
前回の clock=pit だけではまだちょっと早いからね。
 
 


適当に見つくろったこちらの情報を参考に、カーネルを再構築。
>> CentOSのカーネル再構築 - adsaria mood
 

menuconfigのところで割り込みを100HZに変更して新しいカーネルとinitrdで起動してみた。
 

しかし・・・
 
[caption id="attachment_1598" align="alignnone" width="648" caption="画像:カーネルパニック"]画像:カーネルパニック[/caption]
 

カネパ(カーネルパニック)だと?
つーかHDD見えてないやん...これはinitrdの中身がまずいんだよなあ。
手順たらないとかかな?
 
 

原因探しはもうちょっと先でやろう、時刻ずれの応急処置としてはやっぱりntpdateだよな。
 
 
 

仕方なくホストOSのWindowsServer2008をNTPサーバに仕立て上げて5分おきにntpdateする。
これやりたくないんだけどなあ、5分おきのntpdate。。
 

WindowsServer2008 のNTPサーバ化は簡単、レジストリを少々いじる。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config\AnnounceFlags
5 に
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpServer\Enabled
1 に


こんだけ、レジストリを書き換えた後、w32timeを再起動すればOK。
 

少し注意なのは、Hyper-Vではゲストを立ち上げるとそこから見たローカルタイムはWindowsの時間になる。
⇒Windowsが日本時間(UTC+9)で動いてたら、ゲストの基準はそこになる。
ゲストは『UTC+9=UTC』と見てしまう。
という解釈なのかな?とにかくゲストのタイムゾーンを+9にしようもんなら、システムのタイムゾーンは外から見てUTC+18という時間になっちゃう。
 
 


それはいいんだけど、今度はntpdateで問い合わせたら、Windowsは普通にUTCを返す
 

ゲストの時間をUTCにしておく⇒ntpdateで問い合わせたら9時間ずれる。
ゲストの時間をUTC+9にしておく⇒ntpdateで問い合わせる前の時間が9時間ずれている。
 

というなかなか悲しい事態になる、なんじゃいこれは。。
どこに改善要望だしたらいいのか。。『ゲストのhwclockをUTCにしてください?』
ここに書いても拾えないだろうから何処かで受けてほしいなあ。。
 
 

で、結局後者で動かし中。
ntpdateは5分おきなので、起動の瞬間から5分程度だけUTC+18で動いてしまう。
 

ぐぬぬぬぬ。。。
 
 

そのうちカーネルのタイミングを100HZにして、ntpdを動かしたいなあ。
 



カーネルパニックの回避方が判った。
http://sawano.members.icraft.jp/wp/2010/02/07/1666.html
grub.confを編集してね。

2009年11月28日土曜日

Hyper-V上のLinux(CentOS)の時間が早く進むのを何とかしたい

Hyper-VにCentOS5.4を導入してみたが、どうにもせっかちさん。時刻がえらく進む。
 
 

ということでMicrosoftの仮想PC用お勧め設定を実施してみた。
 

The system time runs too fast on a Linux-based virtual machine that is hosted in Virtual Server 2005 R2
http://support.microsoft.com/kb/918461/en-us


 

起動時のカーネルオプションに "clock=pit" を指定しなさいということで、設定の意味もリンク先に書いてある。
 
ちょっち引用。
# Programmable Interval Timer (PIT)
This clock has the following characteristics:

* This clock is set by using the clock=pit kernel parameter.
* This clock uses only the PIT counter for time interpolation.
* This clock uses the simplest of the available algorithms.
* This clock does not gain time because it does not use lost tick correction code.

 

...シンプルだ、ということなのかな。。
 
 

手順通りにgrub.confを修正する。
 
[caption id="attachment_1593" align="alignnone" width="648" caption="画像:grub.conf編集"]画像:grub.conf編集[/caption]
 

で、起動してからntpdateでホストOSと時刻を同期後、少し待って比較する。
 
[caption id="attachment_1595" align="alignnone" width="334" caption="画像:同期してから5分後くらい"]画像:同期してから5分後くらい[/caption]
 

もう結構ずれてる...これでも大分マシになっているのだけど。
これじゃあちょっと物足りないなあ。
 
 

ついでに、サーバ起動直後(ntpdなし)が不思議なんだよね。
 
[caption id="attachment_1594" align="alignnone" width="486" caption="画像:起動時のサーバ時刻"]画像:起動時のサーバ時刻[/caption]
 

なんでホストからさらに+9時間なんでしょうか。
+9時間っつったらインストール時にロケールで日本を選択してるんだけど、調整しておかないほうがイイのかな?
追記:仕様ののようなのでUTCを使うべしという助言をいただきました。
/usr/share/zoneinfo/UTC を /etc/localtime にもってきて変更。

 
 

さらに別の方法を試すので、上手くいったら後編に続く。
 
 



追記:
WindowsServerをNTPソースにするのはこちらを参照しました。
http://d.hatena.ne.jp/hidepon_mory/20071106/1207896724
 

2009年11月27日金曜日

ぶった(切り)、裁断

えー、参考書ぶった切りの季節がやってきました。
 
 

今回の裁断対象はコレ。
 
[caption id="attachment_1590" align="alignnone" width="480" caption="写真:試験区分DBの参考書"]写真:試験区分DBの参考書[/caption]
 



 

切れM@sita-
 
[caption id="attachment_1591" align="alignnone" width="480" caption="写真:裁断!"]写真:裁断![/caption]
 

これを通勤電車読んで特に役に立つわけでもない高度情報処理の試験を受けてきますよー
 
 

...なんて言ってたら仕分けでえらいことにされちゃうのかなー。
だめだなあツンデレが理解できんようでは。
 

まあ冗談抜きで大丈夫かなあIPA、受験料アゲくらいで済めばいいかもだが。
まあそれよりあたしゃあ、お国が心配だよね。
 

2009年11月25日水曜日

CentOS5.4 に 『Linux Integration Components for Microsoft Hyper-V R2』を 導入

前回の続き、折角『Linux Integration Components for Microsoft Hyper-V R2』を探し当てたのでインストールしてみる。
 

やり方は簡単、インストーラはISOイメージの中にあるので、
CDをマウントして、
"./setup.pl driver" と唱えてみる。
 
[caption id="attachment_1585" align="alignnone" width="648" caption="画像:Integration Components その1"]画像:Integration Components その1[/caption]
 

kernel-devel か kernel-sourceがいると、さようか。
 


kernel-devel を yum から入れました。あと当然のようにgccもいる。
 

で、そのあとはCDROMの中身をローカルに移して作業する。
 
mkdir /opt/linux_ic_rtm
cp /mnt/* /opt/linux_ic_rtm -R
/opt/linux_ic_rtm/setup.pl drivers

 


という感じで実行する、書き込み権限があるところに移さないと失敗するのでCDROMからとりあえず場所をうつそう。
添付のPDF読んだらいいんだけどね。
 
 
[caption id="attachment_1586" align="alignnone" width="648" caption="画像:Integration Components その2"]画像:Integration Components その2[/caption]
 


えーと、本能の赴くままインストールしてしまったが、これでどうなるんだっけ...?
 

添付のReadmeを後から読んでみると、どうやら統合サービスが結構有効になる模様。
 
 

これでレガシでないネットワークアダプタが使えたり、ホストとの時刻同期、ハートビートがわかったりするのだな。
インストール後のメッセージにも、vmbusがつかえるだのE-IDE、SCSIとNetworkと書いてある、なるほどvmbus対応はイイネ。
 

あとVSCにも対応できるそうな、透過的に親パーティションの機能が使える?どういう効果があるのかしら、RAWディスクが直接使えたりするのか。
 
 


では普通のネットワークアダプタに接続し直して起動してみよう。
 
[caption id="attachment_1587" align="alignnone" width="648" caption="画像:Integration Components その3"]画像:Integration Components その3[/caption]
 


seth0ってなんじゃい、synthetic nic(ethernet) ってことか。
なんか、本腰入れて作ってる感があって驚いた、能天気にeth0とかで普通に上がってくるもんだと思った。
そうだよね、VMbusだもんな。ともあれ認識&使用もOK。よしよし。
 
 

さあインストールもとりあえず終わった、しばらくテストで動かしてみよー。
まだ時計は激しくずれっぱなしだけどね、ハートビートも見ちゃくれないし。 Integration Components だけじゃ駄目なのかな。
 

Microsoft Hyper-V R2にCentOS5.4をインストール

してみた。
 

特になんの苦労もなしにサクッと入った。
ネットワークは仕組み上、レガシーインターフェイスを選ばないと駄目だね。
 
[caption id="attachment_1582" align="alignnone" width="648" caption="画像:CentOS5.4 on Hyper-V"]画像:CentOS5.4 on Hyper-V[/caption]

 
 

さて、まあどうせ何もしなけりゃ時計がずれるんだよね、仮想の宿命というか。
ということでリリースされたり消されたりしていた『Linux Integration Components for Microsoft Hyper-V』を探しているんですが、誰か行方を知らんかねー
 
追記:
Connectからニュースグループを見たらリンクを教えてくれる人がいた、感謝。
Hyper-V R2 用の Linux Integration Componentsはココだ!
Linux Integration Components for Windows Server 2008 Hyper-V R2 - 日本語
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=c299d675-bb9f-41cf-b5eb-74d0595ccc5c


Microsoft Connect で探しても、肝心のISOイメージが見つからん。
 
 


しかし自宅で触る用のLinuxって何年ぶりだ??軽く10年はそんなことしなかった気がするなあ。
前のはカーネル1.2系だったか...
 
しかしよく見たらsshのクライアントも手元にない (^^;
環境なしなしだ。
 

2009年11月24日火曜日

家に5ポートのギガスイッチを導入する、TCO減らして行こう!

自宅にもスイッチいるよね。
最近のPCはどれを買っても代替1000Baseに対応したNICが搭載されている、ということで折角なのでギガ対応のスイッチを導入することにした。
 
 


さて自宅に置くものとして気になる要素は色々ある。ファンが回るとうるさいし、でかいとやっぱり邪魔なのでポートは5つで十分。
そこらを考慮して、候補を2つに絞ってみた。
 



































































メーカー PLANEX BAFFALO
型番 FXG-05EP LSW3-GT-5EP
製品


対応規格 IEEE802.3:10BASE-T
IEEE802.3u:100BASE-TX
IEEE802.3ab:1000BASE-T
IEEE802.3:10BASE-T
IEEE802.3u:100BASE-TX
IEEE802.3ab:1000BASE-T
AutoMDI/MDI-X
パケットバッファ 104KB 99KB
スイッチング・ファブリック 10Gbps 12Gbps
MACアドレス登録数 1,000個 1,000個
スループット 10BASE-T:14,881pps
100BASE-TX:148,810 pps
1000BASE-T:1,488,095 pps
1000BASE-T 1,488,095pps
100BASE-TX 148,810pps
10BASE-T 14,880pps
ジャンボフレーム 9,216 Bytes 16,000Byte
消費電力 最大4.75W 最大5.5W
ファンレス
未使用ポート節電

 

2製品を比較すると判るように、全体的にバッファロー側のほうが性能が上の印象。
 
バックプレーンの転送量にあたるスイッチングファブリックは2Gも差があるし、ジャンボフレームの最大値に至っては倍近い、唯一パケットバッファが99KBと5KB少ないくらい。
この辺が評価の決め手になってくるのか?
 
 



さあ、ではどっちを買ったか。
 
 
 
 
 
 
 
 
 
 

こっち。
 
[caption id="attachment_1578" align="alignnone" width="560" caption="写真:FXG-05EP"]写真:FXG-05EP[/caption]

 


バッファローのがイイんとちゃうんかい、と思うかもしれないがPLANEXにしたのは理由がある。



  1. 初期コスト



  2. 消費電力


 

この2点でPLANEXのほうが有利だったからだ、先代のスイッチは実に4年も動いていた(何もしなくてもそれなりに熱いという腹の立つ仕様のまま)ので、結局長く使う=目先の性能よりTCOが大事なんだよね、これからは何でも。
 

まあ、積もったところで毛ほどの差しか生まないだろうが、誤差で済みそうな性能の差を無視して、年間でビール一杯くらいの差を確保しようじゃない。
 

ついでにいうと、数年前の100Baseのスイッチ使ってる方、結構それ電力食ってるよ、マジで!今¥3,000-くらいだし、未使用ポート節電タイプに買い替えといてもいいとおもうよ。
常時ONなら1-2年でおつりがくるんじゃないのかな。
 

2009年11月20日金曜日

Windows版のVirtualBoxに、Solaris10の10/09は入らんようだ

タイトルのまんまなのだが、インストーラを起動して暫くしたらPanicで止まる。
 
[caption id="attachment_1576" align="alignnone" width="728" caption="画像:Solaris10 10/09 in VirtualBox"]画像:Solaris10 10/09 in VirtualBox[/caption]
 

panic[cpu0]/thread=fec20160: page_unlock: page fe09cc4b0 is not locked
って...
一体何がやつをそうさせるのか。
 


Windows版VirtualBoxでSolaris10を使いたかったら一個前の 05/09やそれより以前のバージョンは問題ないのでそちらで。
 

2009年11月12日木曜日

Nagiosの状態をステータスバーに表示、FireFoxアドオン『Nagios Checker』

Nagios本体ののアドオン(pnp とか Nagvis とか)で面白いのないかなーと探していたら、別の良いもの発見。
 

FireFoxのアドオン、Nagios Checker
 

NagiosのWEB画面からホスト・サービスのステータスを取得してFireFoxのステータスバーにて通知してくれるアドオンだ。
 

[caption id="attachment_1574" align="alignnone" width="300" caption="画像:Nagios Checker(無風)"]画像:Nagios Checker(無風)[/caption]
 

右下にあるでしょ?Nagiosのステータスが。
異常を発見するとあそこが赤くなり、マウスオーバーで情報がポップアップするというつくり。
管理しているNagiosが一杯あったらとても便利だわこれ、視覚的にすぐ判る分、メールを待つよりいい。
 
 

これでブラウザさえ立ち上げとけばいつもNagiosが一緒だ!監視ライフを満喫しよう。
……しかしどうにも気が重い感じなのは、これを入れるとNagios中心の生活に拍車が掛かるからなのか。
 
 

ついでに設定の仕方メモ
 

  • 定義の名前は何でもいい

  • NagiosのURLはそのまま入力Basic認証はStandalone

  • なぜかスクリプトURLを自動でとらないのでNagiosのURL+"cgi-bin/status.cgi"を手動で入れる。


 

あとは監視間隔や表示領域だの、フィルタ設定だの調整すればOK。
フィルタなんて特に結構かゆいところまで手が届くように出来ている、作者は自分でNagiosを相当使っていそうだ。。
 

あとは設定がエクスポートできれば助かったりしますね、一応ApplicationSettingsの下に設定ファイル本体がxmlでいるので使いまわしたい時はそのファイルを持っていきましょう。

2009年11月11日水曜日

DNSにVRRPという組み合わせはどうなんだろうか

DNSサーバを冗長化する……
っていったら普通は別拠点の別回線とか、全然違うところに置くのが普通の冗長構成です。
外向けのコンテンツサーバとしては大体の場合はそれが一番イイ。
 


さて、別拠点を用意してないとか、中向けのネームキャッシュとして使うとかという時に同じところにDNSサーバを2台並べたりする事もあり。
 

役割の被るサーバが同じ場所にあるならVRRPと組み合わせるとどうかと考えてみる。
 
 



DNSサーバ2台を同じ場所に置く


とりあえず普通に2台並べて置いてみよう。
 
[caption id="attachment_1570" align="alignnone" width="540" caption="画像:DNS2台、普通"]画像:DNS2台、普通[/caption]
 

普通だ、ゾーンとかはマスタ/スレイブで同期してると思ってくれ。
 

片方を遊ばせるのはもったいないので、LAN内のクライアントは適当にクエリ対象を分散させるように優先順を変えてリゾルバを設定した事にする。
 


ああ、図にしてみて思ったがこれでも十分かもしれない。。。
 
 


DNSサーバ2台でVRRPを1つ共有する


最初のでイイかなと思いつつも、折角だからVRRPを使ってみる。
 


図にしてみるとこうなる、まー bind と keepalived かなー。
 
[caption id="attachment_1571" align="alignnone" width="540" caption="画像:DNS2台、VRRP×1"]画像:DNS2台、VRRP×1[/caption]
 

LAN内のリゾルバ設定は統一できる、DNSサーバ1が再起動しても多分すばやめに仮想IPが切り替わるのでアップデートとかメンテナンスの気が楽になるかもしれない。
でもこれじゃあDNS2遊んじゃう。。。
 
 



それならVRRPを2つ共有する?


ルータの勉強してた時だと思うがどっかで見た、VRRP×2を思い出した。
 

構成してみよう、こうかな?
 
[caption id="attachment_1572" align="alignnone" width="540" caption="画像:DNS2台、VRRP×2"]画像:DNS2台、VRRP×2[/caption]
 

おお、こうだよな。
 

DNS1とDNS2で普段から平等に使いつつ、片方落ちたらVRRPで仮想IPを切り替えて生きているほうが落ちたサーバ担当分も引き受ける、復旧まで。
 

これをグローバルIP環境でやるにはIPが4ついる?もったいないかと思いきや、仮想IPだけグローバルでもいけるから2つでも何とかなるかも知れん。
 

これならDNS1が突然永眠した場合もクライアントからは何事もなかったように見えるだろう。
最初の構成では片方に障害が出て、復旧が長引いたときに多少レスポンスがばらつく気がしないでもない。
 
 

もちろん手動で死んだ側のIPを生きてるほうに付けちゃうという手がある、結局IPの手動付け替えをやっちゃうならあんまり変わらんなあ。
そう考えると自動化する手間ばっかりで微妙...
 
 


結論じみたもの


まーちょっとやってみてもいいけど、苦労の割には効果が薄いんじゃないかなかろか。
自動化できるのは規模によってはウレシイが、同時マスタ等、むしろリスクが増加するというマイナス面が心配だ。
 
 

とういことでまとめると、、、
メリットが無くもないがそんなにお勧めでもない、と思いました。
ご利用の際は計画的に。
 

2009年11月7日土曜日

続・ZFS上のiSCSIターゲットをサイズ変更、今度はLVM

前回ext3前々回NTFSとZFS+iSCSIで色々やり、結果がなんだか中途半端だった上『LVMならきっと大丈夫さ!』なんて締めではイカンと思ったのでLVMではどうなったか簡単に書いておく。
 
終始オンラインとはいかなさそうだが、多少はスマートに出来たと思う。
 
 


LVMでもパーティションはさすがに壁


まずちょっと勘違いがあった、LVMのボリューム操作について。
 

物理ボリューム(PV)
ボリュームグループ(VG) にまとめてそこから
論理ボリューム(LV) を切りだしたらその上にファイルシステムを作れる。
 

という所のPVが結構簡単にでかくできると思っていたんだよね、pvresize っていうコマンドあるし。
 

しかし実際は、
こんなパーティション構成でOSをインストールして、
 



















sda1 sda4(ex)sd5 sda3 sda2
ext3 SWAP ext3 LVM(LV00)
/boot SWAP / /data (ext3)

 



ZFS側でケツを拡張してみたら、、、
 






















sda1 sda4(ex)sd5 sda3 sda2 空き
ext3 SWAP ext3 LVM(LV00) ←パーティションの壁
/boot SWAP / /data ←パーティションの壁

 

となり、これでpvresizeを実行してもダメ。
なぜならパーティションに縛られているから、ってことは。
 
 




じゃあパーティションデーブルなんかイラネェや


とある考えのもと、もう一個環境を作った。
 



























sda1 sda4(ex)sd5 sda3
ext3 SWAP ext3
/boot SWAP /
sdb
LVM(LV00)
/data (ext3)

 

HDDは2つ、両方でもいいがiSCSIはsdbだ。
 

で、見たらわかるようにsdbを丸ごとPVにした。
通常見られる createpv では "/dev/sdb1" などパーティション上に作るが、fdiskもしてない状態で"/dev/sdb" にcreatepvしたらこうなる。
これならパーティションの壁を気にしなくていい、だってそんな物(=パーティションテーブル)無いんだから
 
 

この状態でZFSからiSCSIボリュームを拡張する、さすがにLinux側は再起動しないといけなかったが・・・
 












sdb
LVM(LV00) 空き(FreePV)
/data (ext3) -

 

上がってきたLinux上では、きっちりとPVが未使用領域を確認していた、これでpvresize出来る。
 
なぜか自動で一発MAXまで割り当ててくれなかったので一度手動でちょっと大きく(※)したあともう一回pvresizeしたら自動でPVのサイズが最大まで拡張した。
※ここらへんちょっとアヤシイ動きといえるのではあるが。。。
 
 

VG内のPVがでっかくなったので、あとはLVを大きくして、中のファイルシステムを拡張すればOKと。
 
 
追記:某所でつっこまれたので……
もちろん単純にPVを追加してLVを拡張するのみでもOK、というかそれが普通。
iSCSIディスクも拡張するより、もう一個作って接続するほうが真っ当なやり方でしょう。

 
 

ちょっと感想


安易な思い付きってのはなかなか上手くいかないもんです・・・
もっと安全にしたいのであれば、ディスクを追加しPVをVGに入れたあとでリプレースするような感じ、LVMならリデュースかな?をするのがいいかと思います。すっごく普通ですが安全確実でしょう。
 

まあiSCSIディスクはZFS上だったおかげでスナップショットから生み出された幾重ものクローンと、send&recvにより量産されたボリュームを潰し放題と、こういう実験しやすいですね。
 
ついでにVirtualBoxならiSCSIを直接管理できるし、ってこれもSunだなぁ。
 
 

もう本家にならってすっかりSunがスキ!(/sukkri/)」とでも改名したらどうかと思ったりもするが、Windowsだって大好きなので変えない。
 

2009年11月6日金曜日

ZFS上のiSCSIターゲットをサイズ変更、ディスクを拡張して使う(Linux ext3編)

前編、Windows NTFS編からの続きー

 
 

iSCSIターゲットのサイズを拡張して環境変えずに使ってしまおうという目論見のLinux編。
ZFS+iSCSIについては前編に解説
 

使ったのはCentOS5、事前に断っておきたい事ですが記事内では普通のパーティションテーブルに作ったext3を対象に拡張しちゃってますが、普通は初期構築の時点でLVMでやるべきだと思います。
 
追記:LVMやりました。
 


今回拡張に使ったlinuxの環境


すでに結構特殊と言えなくもないが、テストに使った環境について。
 

VIrtualBoxでiSCSIデバイスを管理下のディスクにして、そこに直接CentOS5をインストール。
パーティションはこんな感じ、"/"が一番後ろにあるのがズルいっちゃあズルい環境。











sda1 sda2 sda3
/boot SWAP /

 

最初は8GBのHDDにこれをインストールしました。
 
 

ZFSボリューム拡張してから起動してみる


稼働中に突然拡張、そういえばしなかったなぁ、やってみればよかった。
 
ということで 8GB ⇒ 16GB に増やしたディスクでLinux起動!

容量は……
 
[caption id="attachment_1561" align="alignnone" width="728" caption="画像:増やしたHDDでまず起動"]画像:増やしたHDDでまず起動[/caption]
 
 


増えた増えた(w
もう驚かないぞ。
 

と言ってもいきなり拡張とかできない、パーティションテーブルが変わってないからだ。
さてどうしたもんか。
 
 



パーティションのサイズを変える


変えちゃうかー、パーティションの大きさ。
 

では適当なLiveCDで起動する、今回は手元にあったCentOS5.3のLiveCD。


見た目区別つかんなぁ...LiveCDから起動してますよー
 
[caption id="attachment_1562" align="alignnone" width="728" caption="画像:LiveCDからパーティション操作"]画像:LiveCDからパーティション操作[/caption]
 
 

では操作するディスクに狙いを定め、とにかく "fdisk" と"e2label"コマンドで以下の通り!

  1. "/"を削除 = "/dev/sda3" のパーティション消滅

  2.  
  3. "/dev/sda3" を再作成、残り最大限割り当て
    ※開始シリンダは消去前と死んでも合わせろ!

  4.  
  5. タイプ指定 82 してテーブル書き込み

  6.  
  7. パーティションラベルに"/"指定

  8.  

 

冒険のように見えますか? そうですねこりゃあ大冒険です
 
幸いlinuxのfdiskはパーティションのブートセクタを弄らないのか再作成するのか、このやり方でも後から中身を認識できちゃう。
 
Windows(DOS)のFDISKでやったら即死ですからね、一応HDD解析の鬼みたいな猛者にかかれば復旧の方法は有るみたいですが。
 
 
ではしれっと次に行きましょう。
 
 

ext3ファイルシステムを拡張する


パーティションの準備がすんだら、いよいよファイルシステムを拡張します。
 

シングルユーザで起動とか、甘っちょろいことなしに可能、そのためのコマンドをぶっ叩くまで。


"resize2fs" によって、パーティションの残り容量がちゃんと"/dev/sda3"に割り当てられます。
 
[caption id="attachment_1563" align="alignnone" width="728" caption="画像:ext3ファイルシステム拡張"]画像:ext3ファイルシステム拡張[/caption]
拡張完了めでたしめでたし。
ああ、結構時間かかるので気長に待ってね、たった8Gで10分くらい終わらなかったな。
 
 


あ、inodeとか?そういえば見てなかったな…(汗
いちいちリビルドみたいな事やってるから変わってるのかな。
 
 


LVMだとどうなるんだろう?


この記事の内容は、上手くいっているとはいえ色々なディスクの使用の掟などから完全に目をそむけている気がして正直お勧めはしません。
真っ当にやりたければボリュームマネージャにLVMを使用しておくべきかと思います。。。いやLVM使ってお願い。
 

さて、LVMといえど既存のディスクがいきなり拡張したらどうなるの?という質問をとある方より貰いましたが、実際問題ないと思っています。
後からできた領域は、実際最初からあって使用していなかった領域と同じ扱いになりそうです、16GBのディスクを買ってきて、8GBしかパーティション切らなかったイメージですかね。
 

最初に切ったパーティションの残り容量が0であろうが100GBであろうが、使い始めたらきっと関係ないでしょう。それがいざ拡張しようとしたときに突然現れた残り容量でも然り。
 
 

……と思うんですけどねぇ、実用のためには試してみないといけないなあ。
だれかやってみて!
 
追記:LVMやりました。
 
 
 


追記:なぜ後から拡張したいのか


だって後から容量を柔軟に追加できたら、シン・プロビジョニングが出来るじゃないですかー
今後TCO増加の重荷になりそうなストレージ関係は、裏を返せばコストを減らす事によってグリーンIT推進の原動力になる可能性も十分に秘めている、そこになんとか繋げたいんですよねー。
あとはZFSがデデュープを出来るようになれば・・・!
 

さあいつか役に立てばいいですが。
 

ZFS上のiSCSIターゲットをサイズ変更、ディスクを拡張して使う(Windows NTFS編)

次のLinux ext3編とで前後編。
 

iSCSI経由でマウントしたドライブのサイズを変更して使うというお話。
 


ZFSでiSCSIターゲット


ZFS上にZFSボリュームと呼ばれる容量制限付きのボリュームを作成し、"shareiscsiプロパティ"をonにするとiSCSIターゲットとして利用できる。
 

お手軽高パフォーマンスで重宝するのだが、折角容量可変のZFSを固定容量で使っている気がして、少々もったいないと思っていた。
しかしそれが認識間違いだったのに気づいた、いくらでもサイズ変更出来てしまう
 
 


iSCSIターゲット中のZFSボリュームをサイズ変更


ZFSボリュームは一応普通のZFSファイルシステムとは扱いが違い、独自のプロパティを色々もっているうえOSにマウントされないためzfsコマンド以外では通常見えない。
 

"zfs list"で見るとちゃんと予約したサイズを確保しているので固定だと思い込んでいたが、"clone" とか "send&recv" とかすると利用中サイズが変わる。でもiSCSIでくっつけると見える上限は同じー
 

おかしいと思ってzfsボリュームのプロパティ一覧をみると、 "volsize" とかいうのがある。
どれどれ・・・
 
# zfs get volsize ziscsi/sawa01
NAME PROPERTY VALUE SOURCE
ziscsidev/sawa01 volsize 8G


なるほどZFSボリュームのサイズは単なるプロパティの一つであり、ハードクォータみたいな物なのか。
すっかりファイルをブロックデバイス代わりに使うような感覚でいたよ。
 
 

じゃあ早速、"set" で変更を試みる。

# zfs set volsize=16G ziscsi/sawa01
(特に出力なし・・何か言ってよ!)
# zfs get volsize ziscsi/sawa01
NAME PROPERTY VALUE SOURCE
ziscsi/sawa01 volsize 16G -


おお、変わっちまった、、、
乗せていたNTFSどうなんのよ!?
 
 

ちなみにテストはSolaris10、Zpoolのバージョン15で。
 
 


サイズ変更の瞬間、Windowsでは


サンプルはXP、Vistaみたいにパーティションをゴリゴリいじれないのでどうなるんだろう。。
 
 

まず8Gの時のマウント状況、Microsoft iSCSIイニシエータでZドライブにくっつけ&NTFSフォーマット。
 
[caption id="attachment_1553" align="alignnone" width="553" caption="画像:8GBのiSCSIディスク"]画像:8GBのiSCSIディスク[/caption]
[caption id="attachment_1554" align="alignnone" width="469" caption="画像:8GBのiSCSIディスク(2)"]画像:8GBのiSCSIディスク(2)[/caption]
※実際はSS取るために「8G⇒16G⇒8G」とやったZFSボリュームを使用(^^
 
 



これをZFS側で16Gに拡張するといったんLogoffされる、まあ安全な感じですね。
 
[caption id="attachment_1556" align="alignnone" width="553" caption="画像:iSCSI自動切断"]画像:iSCSI自動切断[/caption]
 
 

では、ログインしなおそう・・・
 
[caption id="attachment_1555" align="alignnone" width="408" caption="画像:MSのWIndows用iSCSIイニシエータ"]画像:MSのWIndows用iSCSIイニシエータ[/caption]
 
 

ディスクの管理を見てみる。
 
[caption id="attachment_1558" align="alignnone" width="553" caption="画像:16GBのiSCSIディスク"]画像:16GBのiSCSIディスク[/caption]
 


増えとるよー!うわー、あたりまえだけど生理的になんだか気持ち悪い。。。
 
 

後はまあ気を取り直して、適当にパーティション操作ソフトでいじるなり、Vista以降なら拡張するなりお好きなようにってところですね。
 

とりあえず手持ちで手っ取り早い方法としてダイナミックディスクにしてみる。
 
[caption id="attachment_1559" align="alignnone" width="553" caption="画像:ダイナミックのシンプルボリューム"]画像:ダイナミックのシンプルボリューム[/caption]
 

変換して追加、ちゃんと8GB ⇒ 16GB のボリュームになりましたね。
ダイナミックディスクって使ったことないけど、相手はZFS上の信頼できるデバイスなのでなんでもイイんです。
 
 

では後編のLinux(ext3ムリヤリ拡張)編に続くー
 
 

2009年11月4日水曜日

テスト用のLANに、とりあえずPPTPでVPNする

検証用に社内にさらにローカルネットワークを組み、こんな環境を作った。
 

[caption id="attachment_1551" align="alignnone" width="474" caption="画像:どこにでもあるテスト環境の概要"]画像:どこにでもあるテスト環境の概要[/caption]
 


作業用のPCからテスト用サーバにアクセスするのに、いちいちルータ兼サーバにログインしたりポートフォワードの設定するのも面倒になってきたのでpptpのデーモン、PoPToPを入れてVPNを張っちゃうことにした。
 

ルータ兼用サーバはCentOS5で作ってたので、インストールは公式のRPMでOK。
 

で、コンフィグした。自分用なので認証無しにしたらとてもシンプル、これだけだった。
 

# cat /etc/pptpd.conf
lock
name pptpd
nodefaultroute
proxyarp
 
localip 10.48.1.254
remoteip 10.48.1.11-15

 

簡単に説明。
まずテスト用LANが 10.48.1.0/24 なのね。
で、PPTPのクライアント用に10.48.1.11-15を払い出そうね、という設定。
 

クライアントはWindows、注意点は「暗号化を必ず要求する」のチェックをはずさないと切断されちゃうことと、IPv4で「リモートゲートウェイを使う」の設定をはずしておくことくらい。
 
ちなみに認証無しの場合はユーザ名/パスワードはなんでもOK・両方空でもOK。不安なので認証したいという人はどうぞ調べて。
 
 

2009年11月2日月曜日

SNIA-Jのストレージ技術セミナー(新大阪)に行ってきた

10/30、SNIA-Jの主催するストレジ技術セミナーの応用編に参加しました。
 

[caption id="attachment_1548" align="alignnone" width="225" caption="写真:SNIAセミナー関連資料"]写真:SNIAセミナー関連資料[/caption]
 

SNIAさんについて詳しくは公式を参照ですが、ストレージ技術の標準化を目指して技術の普及を推進する団体さんです。
...この手の団体さんはたくさんありますが字面だけみると、「世界征服を狙う悪の組織」とかとあまり変わらんですね、信念を持って作戦展開する点など根っこは同じなのでしょうか。
 


冗談はさておき、最近ストレージ関連に関わることが増えてきており、お勉強のためにセミナーに行ってみたのですが、これが面白かった。
一つの物理デバイスからデータセンタの運用まで幅広いテーマでの講演があり、一通り聞いておいて損はない感じでした。
 
 

SNIAさん的にはセミナーに来てほしいでしょうが、ちょっとだけ内容について書いちゃおう、まあ参加は無料だし。
ちなみに講演で引用されまくったオリジナルの英語資料は公開されてるので参考リンク。
http://www.snia.org/education/tutorials/
 
 



ソリッドステートストレージ(SSS)


EMCの方よりソリッドステートストレージ(SSS)について。
 

ソリッドステートストレージ(SSS)ってなによ、SSDは知ってる。
今一般で言うとSSDだとフラッシュの単体ディスク、でもSSDが集合したりDRAMの奴もあろうので、そこらひっくるめてSSSと呼称しようという話が冒頭に。
SSDはSSSの一つだね。
 

そうかー
> ソリッドステートストレージ SSS に一致する日本語のページ 約 115 件

うーん。
 

SSDの技術解説あり、その辺は資料が詳しい。興味深かったのは内部ストライピングでIOPSを稼ぐなど。しっかりお高いSSDはマジで早い。
 

HDDとSSDでは単価が違うが、IOPSや信頼性をベースに試算すると色々用途別の利用法がはっきりする。
システム要件がIOPSベースだと、HDDを20台ストライプしないといけないところでSSDなら1台でOKだったり。
 

とにかく容量単価をって場合は弱くみえるが、消費電力と信頼性を加味して長期的にみると意外とイケる。
場所・消費電力みるとSSD偉く強い。
 
 

ちなみに講師の方が言うに『SSD2010』というやたら詳しい本があるらしい。
http://ec.nikkeibp.co.jp/item/books/184400.html
定価\15,000- 高っ。
 
 

ああ、あとSSDの容量は大分余裕があって、素子が少々ぶっ壊れたり寿命が来ても余分な領域にある代替のものに切り替わるから当面大丈夫みたいな事を言っていた。
言われてみればそうしないといけないのが判るけど、少しどうするのだろうと疑問に思っていた部分なのですっきり。
 
 


ストレージセキュリティ


日立の方よりセキュリティに関したお話。
 

セキュリティ一般論で時間切れちゃった感じ。
個人的に後半の資料がおもしろそうだったので大体知ってる話のうちに終わってしまったのが残念。
ストレージ関連でクラウドサービス内でのストレージの話では、クラウドな為にデータがいつどこに置かれてそれをどうやって特定するのかが難しくなるかもという事が印象だった。
 
 




グリーンストレージ


東芝の方よりグリーンストレージのお話。
 

今回一番のヒット、というか講師のノリがツボでした。。
 

グリーンITが流行っているが、理由が。。。今まで勘違いしていたようだ。
実はグリーンITとは、エコだとか温暖化対策だとかそんな中身のなさそうなボンクラ思想ではなく、『PC関係の消費電力多すぎ!熱出して冷却に金掛かりすぎ!データセンタの維持費たまんねーから何とかしようぜ、つーかしろ!』という実用一点主義だという事を理解することが出来た。
 

これは俄然興味がでてきたよグリーンIT。
iDC運用の悩みの種はやっぱり熱・場所・電力ということで、グリーンITを推進する企業のほとんどが投資効率のUPを狙ってのこと。環境保護は副産物だ、いいぞグリーンIT。
 

さてこの講演で覚えてくれと言われたことがいくつか。
 

その一つが『波及効果』。
サーバの電源を1W節約しました、たかが1W?いやいや、DC変換で0.5、そこに来るまでロスが1W、冷やすの結局1Wで実はiDCトータルで見たら3Wくらい減らせるのだ。
つまり、
これは聖域なき消費電力改革が必要であることを意味する』らしい。
迂闊にもこれでウケてしまった、、、その後も所々で小ネタ的になことやぶっちゃけるような談話など挟まりえらい聞きやすかったな。
 
 

で、あとはストレージの話。
冗長性が求められた結果ストレージ関連設備は肥大化の一途を辿り、消費電力・場所でみた成長率はNo.1だと。
だが容量削減テクノロジーで場所・電力・管理コストを減らしすことでデータセンタのフットプリント削減ができるだろう。
 

シンプロビジョニング、デデュプリケーションなどの技術があれば見た目の容量に比べて実容量は大分減るはず。
 

さてもう一個覚えて帰れという話は、暗号化と圧縮を同時にやりたきゃ、圧縮してから暗号化しないと容量稼げませんよという話でした。
まあごもっともで。
 
 

ストレージ仮想化


最後はNECの方よりストレージ仮想化の話。
 

主に技術より、資料も講演も詳しかったのですが、これは実際に行ったほうがいいや。
記事書くの疲れたとかではなく、何か書いてどうこうという話ではなかったなあという感じ。
 

どこで・どのように仮想化をしてどう見せるかという技術をずらずらと。
 
 
 


と、大体こんな感じでした、東京大阪で年2回ずつやってるようなので、ストレージネットワーク関連を見る人は行ってみては。
 
 


あとはSNIA-Jの資格案内がありましたね。
合格は国内十数名と聞こえました。。数十名?なのかな。。でもほんとに十数名のような気もする。。
なんか狙い目かもです。
 

対策本はこれしかないのかな、まあこれあれば十分のような。
ストレージネットワーキング技術―SNIAストレージ技術者認定プログラム準拠