Windows8 Release Preview版 をFusionにインストールして触ってみました。
新UIのMetroです。（画面の解像度は1366×768にしています）
これまでのWindowsとかなり違って、Windows Phoneに近いものになっています。
ここにタイル状に表示されている項目はメール、IE、SkyDrive等が並んでいます。
左下にデスクトップという項目があって、デスクトップ画面を呼び出すことも出来ます。
デスクトップを開けば、Windows7とそれほど変わらない印象です。
さて・・・と操作しようとすると、あるはずのものがありません。
スタートボタンがありません。焦って探したのですが、やっぱりありません。
ここは諦めて、タスクバーにあるIEとエクスプローラでも立ち上げてみましょうか。
IEもエクスプローラもWindows7と同じで違和感はまったくありません。
仕方無く、Windowsキーを押すと、、、
Metroに戻ってきます(^^;
スタートメニューが出ません(^^;
かなり焦りました。
自宅のサーバを更新しました。
計画通り（計画）です。
実際には増強したかった部分は、
- 64ビットOSをゲストOSとして動かしたい → VT-x対応
- ゲストOSに割り当てるメモリを増強したい → メモリ搭載量のアップ
- そこそこパフォーマンスが欲しい → 最低限Core i系のプロセッサが欲しい
- ２４H稼働させたい → 最低限
という程度であって、それほど高望みをしていたわけでは無いので、
- CPU E3-1265LV2
- メモリ 16GB
- マザーはインテルのS1200KPR
という事くらいです。
HDDも使い回しだし、ケース、電源も安物で揃えました。
当初の予定通りESXi（vSphere HyperVisor）で組めましたけど、ちょっと遠回りしましたね。
MicrosoftのHyper-V Server 2008も考えましたが、システムのインストール容量を考えてESXiにしました。
USBメモリからHyper Visorを起動出来るのは、HyperVisor部分のバックアップを考えても魅力的だったからです。
デスクトップOS等を試してみる場合はVMware Fusionで試してみれば良いし、サーバはESXiで稼働させてみることが出来ますから、、、暇さえあれば色々遊んでみる事が出来そうです。
何かサーバを構築する場合でも、vSphere Converter Standaloneを使うことで、Fusion→ESXi上にV2Vする事、ESXi→FusionにV2Vする事が自由に出来るので、仮サーバを立ててみたり、色々出来そう。
旧サーバはどうなったかというと、vMotionは使えませんが極一般的な手法でバックアップ機として稼働させることにしました。
で、ATOMからXeonに乗り換えた感想として、
滅茶苦茶
速いです。
これまで（UbuntuでProxyサーバロードバランス(1)、UbuntuでProxyサーバロードバランス(2)）構築したとおり、Ubuntu Server 12.04LTSを使ってロードバランサーを構築し、Proxyサーバの負荷分散、障害検知と自動での切り離し、組み込みを動作させるところまで構築しました。
残った問題である、ロードバランサーがダウンしたときに結局システムが止まってしまうという問題に対処するため、ロードバランサーをクラスタ構成してみようと思います。
クラスタ構成と言っても色々ありますが、今回はkeepalivedのVRRPをそのまま使ってロードバランサーをActive / Standby型のクラスタにしてしまいます。
単純にロードバランサー２を追加します。そしてProxyサーバの仮想IPアドレス（192.168.100.10）をVRRPによるフローティングアドレスにしてしまいます。
PROXYサーバをLinuxのLVS（ipvsadm）を使って冗長構成にする事を考えました。
LVSは既に使っている（RedHat Enterprise LinuxでWebサーバロードバランス）のですが、ここではWebサーバのバランシングではなく、Proxyサーバのバランシングを行います。
また、前回の検証時はRedHat Enterprise Linux ES3を使って検証を行っていましたが、今回はUbuntu Server 12.04LTSを使います。ipvsadmがディストリビューションに含まれているため、それにあわせてファイルの配置が変更になります。検証機も実機ではなくESXi上に立てることにします。
今回も目的はProxyサーバの耐障害性の向上で、負荷分散を目的とはしていませんが、構築の順序としては負荷分散機能（ipvsadm）→耐障害機能（keepalived）となります。
※Proxyサーバの仮想IPアドレスは192.168.100.10にする
論理的にはロードバランサーがクライアントからの要求をすべて受けて、２台のProxyサーバに振り分ける構成になるため、図のようにロードバランサーの配下にProxyサーバ２台がぶら下がる構成になります。
物理的には同一セグメントでフラットに接続されている構成になります。
ロードバランサーの構成をNATにしてしまうと、ProxyサーバのアクセスログにクライアントのIPアドレスではなく、ロードバランサーのIPアドレスが記録されてしまう弊害がおきるため、構成はDSRにします。この構成の大きなメリットが２つあり、１つ目がソースIPアドレス（クライアントのIPアドレス）がそのままサーバに伝わることと、戻りパケットの処理にロードバランサーが介在しないことで、ロードバランサー自身の負荷が少なくなる事です。 デメリットはリアルサーバ側に若干細工が必要になることですが、今回はPROXYサーバも自前のため、デメリットになりません。
Proxyサーバの待ち受けポートは8080を使用しています。
ESXi上のゲストOSで動作させているDovecotがお亡くなりになる症状が出ました。
エラーログを見ると
Jul 21 18:39:10 mail dovecot: imap: Fatal: Time just moved backwards by 18 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki2.dovecot.org/TimeMovedBackwards
Jul 21 18:39:11 mail dovecot: imap: Fatal: Time just moved backwards by 17 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki2.dovecot.org/TimeMovedBackwards
Jul 21 18:39:13 mail dovecot: imap: Fatal: Time just moved backwards by 17 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki2.dovecot.org/TimeMovedBackwards
というエラーを吐いていて意訳すると
時間が18秒も戻ってるよ。なんか、すげーヤバイ。オレ、とりあえず落ちるわ。後ヨロ（http://wiki2.dovecot.org/TimeMovedBackwards 見といてね）
とかそんな感じ。
あと、ntpdは時間のズレが激しすぎるとSTEP動作になっていきなり時間を戻してしまうから、-xオプションを付けて起動するか、ntp.confに"tinker step 0"と書いておくこと。
みたいに書かれていたので、その通り/etc/default/ntpに
NTPD_OPTS='-g'
↓
NTPD_OPTS='-g -x'
起動オプションとして -x を追加した。
ただ気になるのが、ntpdで時刻同期をしていたのにOSの時刻が著しくずれていたという点。
普通であれば、ntpdは時間のズレを少しずつ補正する（Slew動作）のだが、そのズレが著しい場合には一気に時間を補正する（Step動作）。ここで問題になっているのはOSの時間が著しくずれていたからStep動作で時間が一気に巻き戻った→Dovecotが時間の巻き戻りを検出して自殺した、という部分なので、ntpdの動作オプションで -x を付けて起動する事でStep動作への切り替わりを発生しにくく抑止したことは対処療法でしかなく、根本的にはOSの時刻が著しくずれていた事が問題になる。
なぜ？
メールサーバはここ何年ずっとDovecotで運用してきている、ntpdの設定もほぼ同じ。その間プラットフォームは色々と移っているが、その間問題無く動いていた。
思い当たる節は・・・仮想化？(ESXi）
そういえば・・・と思い出したのが、VMware Server上でLinux Kernel 2.6を動作させると時間がずれるという話。
仮想化環境でLinuxを動かすときは何かTipsがあったんじゃないかと思い出して調べてみたところ、アタリっぽい。
VMware-toolsの設定でホストとの時間調整を行わない設定にして、時刻同期はntpdのみとした。
$ sudo vmware-toolbox-cmd timesync status
$ sudo vmware-toolbox-cmd timesync disable
全てのゲストOSにその設定を行って、様子を見ることにした。
VMware Fusionを動かしているのがMac mini (2007) Core2 duoの2GHzモデルにメモリを4GB（EFIが32bitなので、3GBまで認識）というちょっと古い機種なんだけど、それでもATOMよりも圧倒的に速い。
やっぱり、ちょっと余裕のあるサーバ機が作りたいなぁ・・・
狙い目は
M/B：Intel DB S1200KPR
CPU：E3-1220LかE3-1265LV2（Ivy-Bridge）
Memory：8GB〜16GB
という辺りか。
別にECCにはこだわってないし、VT-d／VT-xに対応していればESXiも動かせそうなので、Core i5/i7という手もある。
ESXiはLANの対応幅が狭いので慎重に選ばなきゃダメだけど。オンボードNICを殺して、IntelのNICを積めばなんとかなるし・・・HDDはI/O性能に不満が出てきたらiSCSIを検討すれば良いと思っているので。。。
自宅サーバ（ATOM - Intel D510MO）にUbuntu Server の64ビット版をインストールして運用させてたのですが（
自宅サーバ リプレース）、ESXiが5.0になって蟹を認識するようになったとのことで当初の計画通り仮想化（ESXi）する事にしました。
当初の計画としてはD510MOにESXi4.0をインストールして、それまでSolaris10の仮想化（コンテナ）で動作させていた仮想サーバ群をそのまま移行する事を考えていたのですが、D510MOに搭載しているNIC（蟹さん）がESXiで動作しない・・・無理矢理、蟹のドライバ（oem.tgz）を入れて動かすという荒技もあるようですがNICが安定動作しないという情報もあって頓挫・・・という事情もあって、Ubuntu Serverの64ビット版で全部のサービスを一気に動かすという無理な移行をしました。
動作させているサーバというと、
・内部DNSサーバ×3台（自宅内でVlan毎に別のDNSドメインにしているため）・外部DNSサーバ×2台
・メールスプールサーバ（ごく普通のメールサーバです）
・メールリレーサーバ（Clamsmtpdでメールのウイルスチェックをさせています）
・Proxyサーバ（Havpでウイルスチェックさせています）
・ブログサーバ（・・・このブログです。唯一重いサーバです。）
と、元々仮想化していたサーバ群なので、負荷的には全然軽いサーバばかりです。
仮想化していたサーバを1台に無理矢理集約していたのでDNSサーバが面倒な構成になっていて、外部と内部向けのDNSが共存していることと、内部向けに個別のDNSドメインが存在しているからViewを使ってしまうとスレーブサーバのゾーン転送が難しくなることから、サーバ内に個別のBINDを立ち上げて運用させていました。そして、どうしてもNICが2枚は必要だったのでIntelのPCI NIC（82541PI）を増設していました。
Google先生に「Linux リゾルバキャッシュ」とか聞くと、無い！と答えが返ってきますが、
残念ながらnscdとか言うのがあります。
普通にservice nscd stopとかすれば止まりますが。。。
SRXのトラフィックログ、普通にセキュリティポリシーの中でセッションログの設定があってsession-initとsession-close時にログを記録する事が出来ます。
セキュリティポリシーの設定時に
user@host# set security policies from-zone trust to-zone untrust policy default-permit then log session-close
user@host# set security policies from-zone trust to-zone untrust policy default-permit then log session-init
みたいにログ記録を指定出来るのですが、
デフォルトでは出力されないので、ログに関する設定が必要だったりします。
user@host# set system syslog file traffic-log any any
user@host# set system syslog file traffic-log match "RT_FLOW_SESSION"
とここまではJuniperのページにKB16509として載っていて、ここまで設定することで
トラフィックログをファイルに書き出すことが出来ます。
ですのでこの状態ではコマンドラインから
user@host> show log traffic-log
トラフィックログを見る必要があります。
J-Web(GUI）にはNetscreenと似たアイコンが表示されるので、クリックすれば見れるのが当たり前に思うのですが、そうはなっていなかった。
普通にここまで設定をして、View Logのアイコンをクリックしても、ログは表示されませんでした。
結論を書いてしまうと
user@host# set security policies trace options file policy-trace
user@host# set security log mode event
はっきりしていないのですが、このあたりの設定（出力ファイルまで指定）をしていた当たりから、ログが見れるようになったようです。
それにしても、SRXはやれること（例えば、VR毎にFlowベース処理を止めて単なるルータにしてしまうことも出来る）も多いのですが、反面他のファイアウォールが当たり前に（かつ簡単に）出来ていることが、簡単に出来なかったりと、かなり灰汁が強い感じですね。
