VPSを利用した自宅サーバー機能分割の検討近況
自宅サーバーの場合 機器の構成変更や増減設などの物理作業がいつでもできるのが利点ではあるもの、音や電気代、可用性などを考えると少し問題がある。メールサーバーなど、比較的可用性を高く保ちたい機能から順次VPSに移設できないか、去年から検討してきた。
最近のVPSはたいてい契約前に一定期間無料で無償でテスト利用できるため、これまで数社試用してみたのだが、いずれも採用不可だろうと移設を断念した。当時VPSに載せようとしていた機能としては、Apache、MySQL、Mailmanなどといった比較的軽量な構成ではあったのだが、致命的な問題としては「スワップが利用できない」点だ。
VPSサービス提供業者では、Virtuozzo(オープンソース版だとOpenVZ)を採用しているケースが殆どであり、スワップ不能な原因はここにある。Virtuozzo以外にはXenやVMWareなどを採用しているケースもあるが、全体に占める割合でいえば圧倒的にVirtuozzoが採用されている。これは一重に「高度な仮想化テクノロジーの運用スキルがなくても、ライセンス料を支払うことでサービス提供環境が手に入る」ことに依存する。とにもかくにも、VPS≒Virtuozzoという状況の中、VPS環境でスワップが利用できない点やメモリのオーバーコミットができない点は国内・海外を問わず状況は全く同じで、VPS採用可否の課題となっていた。無論XenやVMWareベースのVPSサービスであれば問題ないわけだが、費用的には1.5〜2倍程度が相場となるため頭の痛い点だ。
以前の試用期間でVPS環境を体験したあと、OpenVZで環境を自前で用意し色々と調査してみた。OpenVZとVirtuozzoの違いについては 参考サイト の内容を参照するとして、根本的な機構そのものに大きな違いはないものとして検証した。
以下、検証結果と考察
- ゲストOSでスワップを使わせること自体は技術的には可能(bustable memoryの設定次第)
- ただしbustable memoryの値を大きく設定しすぎた場合、実際に設定値までメモリ要求があった場合にスラッシングが発生するため、複数のサービス利用者の環境が同居するVPSサービスでは現実的な設定ではない。これはなんとなく納得。
- とは言えスワップやメモリオーバーコミットができない条件下で、512MB程度のメモリサイズでどの程度のことができるだろうか？元々想定していたレベルでは使えなさそう。
高可用性・高信頼性が必要な重要なシステムなどの商用用途であれば、IBM社のMCCSなどに見られるような業務システム向けサービスを採用するのが無難だろう。ただ少なくとも私の場合、VPSの利用目的は小規模(パーソナルユース)なシステム用途であり、メモリやCPUなどのリソースを増やす＝ランニング費用が月額5,000円くらいになる、というのはあまり現実味がない。最近はVirtuozzoベースでのVPSでもCPI社のサービスではスワップが利用可能な構成で売り出し始めた模様。もう少しVPS市場の動向を見守るべきか。
前述のようにVPS市場では圧倒的にVirtuozzoが採用されているわけだが、そんな中 さくらインターネットのVPS が仮想化機構にKVMを採用している点は興味深い。既に周知の事実だが、RedHat社はRHEL6からXenを廃止し、仮想化機構としてKVMのみに一本化する姿勢を明確にした。大手SIベンダーの商用仮想化サービスでもVMWareの一人勝ちからKVMベースでのサービスを並行する動きも見られ、今後の動向が気になるところだ。
Windowsサービス一覧をコマンドで取得する
サービスの状態を確認したい時や、OS構成のパラメータシートを書く時など、Windowsサービス情報の一覧をコマンドで取得できると何かと便利なことがあります。今回はそんな時の手順を。サービス一覧の取得はscコマンドを使います。取得したいサービスの状態が開始(RUNNING)か停止(STOPPED)かによって若干オプションが違ってくるものの、いずれも非常に簡単。
- 全サービスの一覧を取得
- 「state= all」がないと、稼動中のサービスのみの一覧となる。
sc query state= all
- 停止中のサービス一覧の取得
sc query state= inactive
- 実際の使用例･･･あるVMWare関連サービスをコマンドで手動起動する場合
- (1)正確なサービス名が思い出せないので確認
C:\>sc query state= all | findstr ^SERVICE_NAME | findstr VM
SERVICE_NAME: VMAuthdService
SERVICE_NAME: VMnetDHCP
SERVICE_NAME: VMware NAT Service
SERVICE_NAME: VMwareHostd
SERVICE_NAME: VMwareServerWebAccess
-
- (2)サービスの状態を確認
C:\>sc query VMwareHostd
SERVICE_NAME: VMwareHostd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 1 STOPPED
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
-
- (3)サービスを起動
C:\>net start VMwareHostd
VMware Host Agent サービスは正常に開始されました。
VMWare Server 2.0上のUbuntu 10.10にOpen-VM-Tools導入
VMWare Server 2系でVMWare Toolsのインストールがうまくいかないこと、多いなぁと思う今日この頃。家の古いPCを徐々にLinuxに入れ替えているのだが、Ubuntu 10.10へのVMWare Toolsが入らず、ちょっと悩んでしまった。シューティングしたところ、途中までは以前書いた記事(VMWare Server 2.0上のFedora 14にVMWareToolsをインストール)にも似た状況だったのだが、続けて調べていったものの解決できず。
そこで今回はちょっと趣向を変えて、VMWare純正のVMWare Toolsを使うのはやめて「Open-VM-Tools」を使うことにした。Open-VM-ToolsはVMware Tools のオープンソース実装版で、機能的には純正のVMWare Toolsとそれほど変わりはない。
仮想マシンへのOS導入後の状態のままでは不便なので、解像度の自動変更 (autofit) やマウスポインタの透過、クリップボードの共有を行うため、Open-VM-Toolsをインストール。
稀に解像度の自動変更 (autofit) がうまくいかない場合があるが、この場合はUbuntu の起動後、VMware Remote Console を一度終了させ、再度 VMware Remote Console を起動すればOK。
$ sudo apt-get install open-vm-source open-vm-toolbox open-vm-tools open-vm-tools-dbg
spfileからパラメータを削除する方法
備忘録。spfileに書き込まれたパラメータを削除するには、下記SQLを実行する。(parameter_name), (ORCL)には適切なものをセットする。
alter system reset (parameter_name) SCOPE=SPFILE SID=’(ORCL)’;
VMWare Server 2.0上のFedora 14にVMWareToolsをインストール
Fedora 14が出たので検証してみようと思い、普段使っているWindowsXP上にインストールしたVMWare Server 2.0上の仮想マシンとしてFedora 14(32bit)を導入してみた。OSのインストールは別段問題なかったのだが、VMWareToolsをインストールするのに少々ハマったので備忘録としてメモしておく。ちなみに、VMWare ServerではなくESXi 4.1で運用しているサーバー上の仮想マシンとして導入してみたところ、特に問題なくVMWareToolsがインストールできたので、VMWare Server 2に付属するVMWareTools側の問題なのだろう。
まず、問題が起こっていた環境はこう。仮想マシン作成時のOSタイプは「Other 2.6x Linux (32-bit)」。
VMWareToolsはtarballを解凍しコンパイルでインストールしようとしたのだが、カーネルヘッダー格納場所の指定のところで困ってしまった。Fedora 14ではデフォルトの「/usr/src/linux/include」ではなく「/usr/src/kernels/2.6.35.10-74.fc14.i686/include」に格納されるため、手動で指定してみたのだが、どうもうまくいかない。
# cat /etc/redhat-release
Fedora release 14 (Laughlin)# uname -a
Linux XXXX 2.6.35.10-74.fc14.i686 #1 SMP Thu Dec 23 16:17:40 UTC 2010 i686 i686 i386 GNU/Linux
色々と調べた結果、インストーラ(vmware-install.pl)では指定したカーネルヘッダーの格納先ディレクトリの配下にある include/linux/version.h に記載されている「UTS_RELEASE」のコメント行を見て判断されるようだ。そこでversion.hに以下の内容を追加する。(ただし、仮想マシンを作成する際にOther Linuxを選択しない場合には異なる動作になると思われる)
What is the location of the directory of C header files that match your running
kernel? [/usr/src/linux/include] /usr/src/kernels/2.6.35.10-74.fc14.i686/includeThe directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match
your running kernel (version 2.6.35.10-74.fc14.i686). Even if the module were
to compile successfully, it would not load into the running kernel.What is the location of the directory of C header files that match your running
kernel? [/usr/src/linux/include] /usr/src/kernels/2.6.35.10-74.fc14.i686
今回修正した「/usr/src/kernels/2.6.35.10-74.fc14.i686/include/linux/version.hの内容は以下の通り。
#define UTS_RELEASE "(uname -rの結果)"
修正が終わったら、VMWareToolsのインストーラを再実行する。
# diff -u version.h.orig version.h
--- version.h.orig 2010-12-24 01:23:01.000000000 +0900
+++ version.h 2011-01-08 22:47:43.644119397 +0900
@@ -1,2 +1,3 @@
#define LINUX_VERSION_CODE 132643
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
+#define UTS_RELEASE "2.6.35.10-74.fc14.i686"
これでようやく先に進んだ。やれやれ。この先で細かなエラーがいくつか出るが、無視して一旦終了して問題ない。この後「/usr/bin/vmware-config-tools.pl」を実行しX周辺の設定などを行って作業完了。実務でのVMWare系の仮想化ソフトとしてはハイパーバイザー型のESXやESXiを使う場面しかなくなってきているが、気軽にPCで試したい時にはまだVMWare Serverを使ったりするなぁ。
What is the location of the directory of C header files that match your running
kernel? [/usr/src/linux/include] /lib/modules/2.6.35.10-74.fc14.i686/build/includeExtracting the sources of the vmmemctl module.
Building the vmmemctl module.
(後略)
