管理PCで管理したい場合は「Hyper-V Server R2導入 3時間クッキング」の記事でも見てください。
シチュエーション
- このサーバはインターネット(sshトンネルされたrdp 7.0)経由で管理できるようにする。
- sshdは別途用意されており、インターネット経由でログイン可能になっているものとする。
- 用意出来ないならルータを設定してRDPポートを直接開放しても良いがセキュリティに十分注意する。
- 管理用の端末はrdp 6.0にも対応出来るようにする（MSは非推奨だがsshを経由しているので良しとする）
- Windows XPはrdp 7.0に対応していない。
- 管理PCはサーバと同一のサブネットには存在しない。よってHyper-Vマネージャも使えない。
- Windows 7が無いとHyper-Vマネージャが用意できないのでRDPに頼ることになる。
- 仮想環境ももちろん管理できるようにする。今回は以下の仮想環境を導入した。
- Windows Web Server 2008 R2(常時起動)
- Windows Web Server 2008 R1 x64(正式名称ではないが便宜上R1と記載)
- CentOS 5.4 x64(常時起動)
- CentOS 5.4 x86(常時起動)
- Windows 7（後に撤回）
- Windows Vista(今回は用意しなかった)
- Windows XP（後に撤回）
- ディスク構成の要件
- ディスクの故障によりシステムが停止しないよう、システムディスクはRAID1で構築する。
- パフォーマンスの確保のためにVHDは固定ディスクとする。
- VHDを配置するディスクに十分な空き容量を確保する。
- 物理メモリを8GB実装する。また、Hyper-Vの都合により、メモリと同容量のハードディスク領域を確保する。
- システム用のハードディスクの他にデータ用のディスクを接続する。これは仮想環境からのみアクセスする。
- ディスク構成
- C: (1TBx2 ハードウェアRAID1)
- D: (データ用のディスク。Hyper-Vからはオフラインとする)
- DVDドライブ(OSインストール後は物理的に取り外す)
導入の初期設定
- ホストOS用の GRMHVxFRE1_DVD.iso ダウンロード。
- http://technet.microsoft.com/ja-jp/evalcenter/dd776191.aspx
- DVDへの書き込み。InfraRecorderの出番か。
- ホストOSをインストールする。2～3回再起動。パスワードの設定。
- コンピューター名(hypervhost)の変更。再起動。
- ローカル管理者(hyperv)の追加。パスワードの設定。
- リモートデスクトップ。有効。RDP 6.0に対応させるなら「低」。さもなくば「高」。
- ここからは同一サブネット内からリモートで作業可能。
- リモート管理の構成。 Windows PowerShell を有効にする。再起動。
- 更新プログラムのダウンロードとインストール。a。a。(すべて適用)。再起動。
- ネットワーク設定。DHCPを無効。IPアドレスを設定。DNSサーバを指定。
ホスト管理のための設定
コマンドはすべて黒い窓に打つ。
// firewallを全部offにする(必要ないかも。offにしなくてもrdpとファイル共有は使える)
netsh advfirewall set currentprofile state off
// 共有フォルダ share を作成する
mkdir c:\share
net share share=c:\share /grant:hyperv,full
// 共有フォルダ share の共有を解除する
net share share /delete
// ユーザーのパスワードの有効期限を無期限にする
wmic useraccount where (Name = "Administrator") set PasswordExpires=False
wmic useraccount where (Name = "hyperv") set PasswordExpires=False
// ユーザーのパスワードの有効期限を確認する
wmic useraccount where (Name = "Administrator") get PasswordExpires
wmic useraccount where (Name = "hyperv") get PasswordExpires
VMを管理する
PowerShell Management Library for Hyper-V
http://www.codeplex.com/PSHyperv
PDFと本体の両方をダウンロードしておく。コマンドが多すぎる上にメニューが無いので使い勝手は悪い。
ところで、今回はWMIの設定もfirewallの設定もしてないのに、管理PCから接続できた。なんでだろ・・・。
PowerShellで打つコマンド
// ダウンロードして展開したPowerShell Management Library for Hyper-Vのインストール
cd (共有フォルダのパス)
cd HyperV_Install
install
// PowerShellを起動する
powershell
// スクリプトを読み込むためのセキュリティ設定の緩和
Set-ExecutionPolicy Unrestricted
// スクリプトを読み込む（毎回必要？）
Import-Module 'C:\Program Files\modules\HyperV\HyperV.psd1'
// VMの一覧を取得
get-vm
// VMの新規作成
new-vm -name "hoge"
// VHDを容量固定に変換
PS E:\g> convert-vhd -VHDPaths "変換元" -type "Fixed" -DestPath "変換先"
// w2k8r2の事例
new-vm -name "w2k8r2"
set-vmmemory "w2k8r2" -memory 2048MB
set-vmcpucount "w2k8r2" -CPUCount 1
set-vm -vm "w2k8r2" -autoStart AlwaysStartup
add-vmdisk "w2k8r2" 0 0 'VHDのパス'
add-vmnic "w2k8r2"
start-vm "w2k8r2"
get-vmsummary "w2k8r2"
// 終わり
exit
現時点でわからないこと。
- 「仮想ネットワークマネージャ」の「新しい仮想ネットワーク」に相当するコマンド操作。たぶんSwitchに関係するのだと思う が・・・。
- VMの設定で上記仮想ネットワークに接続する方法。たぶんSet-VMNicSwitchだと思うが設定しても変化がない。
- 仮想環境に「接続」する方法。
- vmconnect.exeをサーバにコピーしたら、起動したが接続できずに待たされ続ける。
- Windows 7 amd64用のHyper-Vマネージャをインストールしようとしたが拒否された。
仮想ネットワークを増やすような運用はいまのところ予定していないからいいが、VMの追加は普通に想定される。
その都度、管理PCを用意して運用しなければいけないとしたら苦痛にもほどがある。
物理ディスクを管理する
LSI MegaRAIDみたいなサードパーティ製ソフトウェアRAIDを使うと苦労する。
Hyper-V R2に監視ツールをインストール出来て、RAIDの状態を自動通知出来るハードウェアRAIDを探すか、
さもなくばWindowsの標準機能でお茶を濁す方が無難。
また、仮想環境から物理ディスクにアクセスするためには、事前に物理ディスクをオフラインにする必要がある。
これらは diskpart というコマンドで操作する。
// diskpartを起動する。
diskpart
// ディスクの一覧を出す
list disk
// ディスクを選択する
select disk 1
// 選択したディスクをオフラインにする
offline disk
// 別のディスクをミラーするために追加する
add disk 2
// 終わり
exit
// 以下はコマンドプロンプトで実行
// ボリュームの状態を標準出力に吐き出す(都合上diskpart.txtというファイルが生成されるので注意)
// あとはこのファイルを解析して処理するスクリプトなどを別途作成すれば良いはず。
echo list volume > diskpart.txt
diskpart /s diskpart.txt
2010-03-08 19:39:02
Maniax
Comments: 0
先月の頭にHyper-Vサーバが起動しなくなった。
リモートで症状が確認できない深刻な状態だったので、ローカルで電源投入すると、なぜか無事に起動した。
しかし、筐体からジジジジジジ、キュッキュッ、というひどい音がする。
そしてすべてのレスポンスが異様に遅い。
ローカルだとすぐに気づくのに、リモートだと気づかない罠。ハードディスクの経年劣化だ。
どうやってこういうのをリモートから判定すればいいんだろう。
Hyper-VホストにS.M.A.R.T.監視ツールとか、そういうのを入れられるんだろうか？
仮想ディスクに対してはそういった監視は一切出来ないから、ゲストOSじゃ対処しようがないし。
参考までに、ベンチをとってみた。まずは一番最近増設したデータ用のSATA2物理ドライブ。
--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------
Sequential Read : 123.145 MB/s
Sequential Write : 100.825 MB/s
Random Read 512KB : 28.576 MB/s
Random Write 512KB : 82.514 MB/s
Random Read 4KB : 0.616 MB/s
Random Write 4KB : 1.998 MB/s
Test Size : 100 MB
Date : 2010/03/08 13:23:49
で、次が問題のブートディスク上にある仮想ディスク。
--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------
Sequential Read : 4.388 MB/s
Sequential Write : 1.896 MB/s
Random Read 512KB : 3.612 MB/s
Random Write 512KB : 1.301 MB/s
Random Read 4KB : 0.089 MB/s
Random Write 4KB : 0.120 MB/s
Test Size : 100 MB
Date : 2010/03/08 12:42:29
格安のUSBメモリよりひどい。
ハードディスクだけNECに送れば無償交換に応じてくれるんだろうか。
本体送るのはめんどくさすぎて嫌なので、パーツ単位の交換がダメなら泣き寝入りするしかないけど。
VMWareみたいにUSBメモリでブート出来たりすると便利なのになあ。
2本さしておいて非常事態に備えるとか、そういう使い方まで出来れば尚更良い。
さもなくば、ブートディスクをRAID1にするとか、そういう必要性が生じてくるのかも知れない。
Hyper-Vマネージャの「RPCエラー」みたいなのは、実はユーザのパスワードの有効期限切れらしい。
設定方法
wmic useraccount where (Name = "Administrator") set PasswordExpires=False
wmic useraccount where (Name = "hyperv") set PasswordExpires=False
確認方法
wmic useraccount where (Name = "Administrator") get PasswordExpires
wmic useraccount where (Name = "hyperv") get PasswordExpires
リモートデスクトップを開放していないと設定すら出来ないので、導入直後に設定したほうがいいかも。
2010-03-01 00:13:42
PHP mysql
Comments: 0
すんなりとはうまくいかないのでメモ。
データベースの「操作」メニューからデータベースをコピーすると、
恐らくテーブル名のアルファベット順にコピーを試みるため、
アルファベットの後ろにあるテーブルに依存したテーブルを作成しようとするとエラーになる。ださい。
ところが、エクスポートされたsqlを見ると、
最初にすべてのテーブルの構造を仮作成して、実際のテーブルの作成時にDROPして作り直している。
このやり方だと、依存の順番を解決する必要すら無くなるので合理的である。かしこい。
というわけで、データベースのコピーをとりたいと思った時は、
- まずエクスポートする。
- 新規データベースを作成する。
- そこにインポートする。
という手順をとればすんなりOK。かんたん。
関係無いが、phpMyAdminは便利機能としてhoge_ではじまるデータベースをhogeユーザにすべて見せようとする。
適切な認証管理が行われていれば当然みえなくなっていると思うが、
hogeユーザに見せたくないデータベースを持つときは、hoge_miruna ではなく miruna_hoge という名前にしといた方が無難かも知れない。
いままでのまとめ。
設計を考えた結果、意外にもMVCの原点に立ち返ってしまった。
今まで自分はMVC否定派だと思っていたがそんな事は無かったぜ。
MVCを正しく成立させるためには、M-V-Cがそれぞれ対等でなければいけないのだ。
symfonyもcakeもMが強すぎる。Vが弱すぎる。
その結果Cが調整弁として多くの役目を果たさねばならず、肥大化する羽目になる。
アクションをシンプルにするのはフレームワークの命題だと言えるので、それではいけない。
対等なMVC。
- コントローラ
- ルーティングを行う。ルーティングはアクションに相当する処理を行う。
- アクションに相当する処理にはすべて必ずルート定義が与えられる。アクション内で分岐が行われて2つの動作を1アクションに記述する事はありえない（禁止）。分岐が起きる場合、一方の処理は別アクションへの変更という形で処理する。
- ルート定義には従来通りワイルドカードを用いる事が出来る。標準の規約では、URLに該当するビューを（アクションが定義されていなくても）呼び出す事が出来る。ビューのファイル名はルート定義により決定される。
- よって、アクションはビューの面倒を見る必要性から解放される。Smartyのassignに相当する処理は暗黙に行われる。アクションによって明示的に変更しても良い。
- アクションに相当する処理は、原則的に設定ファイルに記述する事が出来る。個別のロジックが必要な場合は、そのロジックを指定して呼び出す。（これはstruts.xmlに似ている）
- ビュー
- ビューはassignされた変数群とファイルのパスを受け取る。
- ビューの設定はビュー専用の設定ファイルに記載される。
- ビューは「受け取ったパスから実際にどのファイルを呼び出すか」を設定する権限を有する。これはアクションのsetTemplate()に相当する。
- ビューはインクルード機能を有する。これを使い重複する実装をまとめる事が出来る。これはウィジェットの管理にも必須の概念である。
- ビューはDOCTYPE宣言やヘッダ送出のために、自身の親となるファイルをインクルードする事が出来る。これは設定ファイルに記述する。
- ビューはウィジェットを有する。たとえばPOSTリクエストを送信する方法はビューが決める。フォームなのかAjaxなのか、どんなインタフェースで送信させるのか、すべてビューが決める。
- 以上の要件から、Webデザイナーは以下の事項を学習する事で開発に参加する事が出来る。
- ビューの設定ファイルの記述方法
- テンプレートエンジンに対応するコーディング方法
- ウィジェットの定義と利用方法
- そして、当該プロジェクトにおける個別のルート定義（先行開発の場合はワイルドカード）
- モデル
- 機能群とテーブルは一対一で結びつかないという経験から、機能群とは異なる。あくまでテーブルに関する操作しか実装されない。
- ロジック
- ロジックはMVCから分離されるが、MVCの要素をそれぞれ内包する。（これはcakeの考え方に近いのかも知れないが、真意はわからない）
- モデルを操作するための機能群が含まれる。
- コントローラに追加のコーディングが必要な場合はロジックが呼び出される。
- ビューのウィジェットを実装するのに必要であればロジックが呼び出される。
- ライブラリ
- ロジックはプロジェクトに対して実装されるもので、ライブラリはフレームワークに対して実装されるものであると定義する。
- ライブラリはロジックの代替になることが出来る。もちろんロジックからライブラリを呼び出すことも出来る。
これでだいたい、作りたいフレームワークの骨格は設計できた。
あとは具体的に実装をはじめていこうと思う。
オープンソースプロジェクトにしたいのだが、作法がわからない。
これは書き直しではなく続き。
「フォーム」はビューの管轄である。
（ただし「バリデータ」はモデルの管轄である）
symfony 1.4用語で言うと、errorsとhelpsとwidgetsはビューの管轄ということだ。
ただし、errorsはバリデータを取り扱うためにモデルを必要とする。
当然、保存処理を実行するためにもモデルが必要だ。
コントローラ≠モデルと定義してしまったので、「どのモデルを使うか」を記述しないといけない。
ビューはアクションと同数のビューを持つ。
newアクションとeditアクションで同じビューを使いたければ、そのようにビューが設定する。
ビューにはそれを設定する仕組みを提供する必要がある。
あるテンプレートファイルは別のテンプレートファイルをインクルードする事が出来る。
symfonyのlayout.phpも、親子関係は逆転しているが、インクルードの一環である。
どの親をインクルードするかも、設定ファイルに記述する。
インクルードされるファイルはアクション名と結びつかないため、
「テンプレートファイルがあれば必ず同名のアクションが存在する」とは言えない。
便宜上、たとえばファイル名の先頭に_をつけて区別すると良いかも知れない。
デバッグモードでは、アクションが存在しなくてもルーティングとテンプレートを結びつける事が出来る。
これはモックアップ作成のために必要である。
デザイナー視点だと、これを本番モードでも適用させれると良いのかも知れない。
ルート定義＝アクション＝ビューとするわけである・・・。
/ と /default と /default/index が同じビューであることを、ビューが定義する必要がある。
/hoge/fuga と /foo/bar が同じだとしても同様である。
ひょっとすると、そっちのほうがいいのかも知れない。
最も設定のボリュームは多くなるが、定義は透明になる。
この場合、バリデート失敗もひとつのアクションとして定義する必要がある。
システムエラー的なものも含めると、より数は増える。
そのかわりアクションはルート定義と完全に同化する。「コントローラ」になる。
なんてこった。一回りして完全なMVC構造になってしまった。
この仕組みにはもう一つメリットがある。
必ずすべてのビューにルートが割り当てられていると、ダミーデータを用いた表示テストが容易に出来るのだ。
もちろん、すべてのパラメタ（たとえば権限管理とか）を適用するのは難しいが。
