ウェブ開発者のための、1時間でできるLAMP環境構築術(CentOS編)

  • 投稿日:
  • by
  • Category:

最近、さくらのVPSやServersmanなど格安のVPSサービスや、Amazon Web ServicesやNiftyクラウドに代表されるクラウドサービスなどの台頭により、以前よりもサーバを使うことのハードルが下がりました。
そのためウェブ開発者がサーバの運用に関わる機会が増えていますが、ApacheやMySQL、PHP(Perl)などのいわゆるLAMP環境を作るには、意外と手間がかかることに気づかされます。
そこで、今回は1時間で出来るサーバセットアップを目標に、LAMP環境構築のチュートリアルとまとめました。

この手順においてはCentOSの基本的な設定が完了しているものとします。
参考:CentOSをサーバーとして活用するための基本的な設定(さくらインターネット創業日記)
なお、この記事はCentOS 5 もしくは CentOS 6 の64ビット版をベースに書いていますので、これ以外のOSの場合には適宜読み替えて下さい。

CentOS 最新版へのバージョンアップ

今回の作業を行うにあたって、対象サーバがCentOS 5.5であったため、yum upgradeを実行して CentOS 5.6へバージョンアップしました。
現在(2012/5/7)の最新バージョンは、CentOS 5.7 もしくは CentOS 6.2 です。バージョンアップを行うと、それぞれ最新版のCentOSへとアップデートされます。
すでにCentOS 最新版の場合には以下の作業は行わなくてもかまいません。

[root@ ~]# rpm -qa | grep centos-release
centos-release-notes-5.5-0
centos-release-5-5.el5.centos
[root@ ~]# yum upgrade -y
Loaded plugins: fastestmirror
Determining fastest mirrors
色々出てくる
Total download size: 162 M
Downloading Packages:
色々出てくる
Importing GPG key 0xE8562897 "CentOS-5 Key (CentOS 5 Official Signing Key) " from /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[root@ ~]# rpm -qa | grep centos-release
centos-release-notes-5.6-0
centos-release-5-6.el5.centos.1 ← CentOS 5.6へとアップグレードされた


yumのリポジトリ追加

yumとは各種ソフトウェアをパッケージという単位にして、簡単にインストール・アンインストールするための仕組みのことです。
リポジトリを追加することによって、パッケージのダウンロード元サイトを増やし、インストールできるソフトウェアのバリエーションを増やすことが可能です。
標準のリポジトリではPHPの最新バージョンなどが用意されていませんので、今回は Fedora EPEL 、remi、RPMForge という3つのリポジトリを追加します。

はじめに、Fedora EPELのダウンロードを行います。

CentOS 5 の場合

[root@ ~]# wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm

CentOS 6 の場合

[root@ ~]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm

※download.fedora.redhat.comに繋がらない場合には上記の通りdl.fedoraproject.orgに変更すればダウンロードできます。

上記のファイルが無くなっている場合には、次のURLからepel-release-で始まるファイルを探してダウンロードして下さい。
http://dl.fedoraproject.org/pub/epel/5/x86_64/ (CentOS 5)
http://dl.fedoraproject.org/pub/epel/6/x86_64/ (CentOS 6)

次にremiのダウンロードを行います。

CentOS 5 の場合

[root@ ~]# wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

CentOS 6 の場合

[root@ ~]# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

上記と同様に、ファイルが利用できない場合には、以下のURLからダウンロードして下さい。
http://rpms.famillecollet.com/

最後に、RPMForgeのダウンロードを行います。

CentOS 5 の場合

[root@ ~]# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

CentOS 6 の場合

[root@ ~]# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

上記と同様に、ファイルが利用できない場合には、以下のURLからダウンロードして下さい。
http://dag.wieers.com/rpm/packages/rpmforge-release/

それでは、3つのリポジトリを追加します。

CentOS 5 の場合

[root@ ~]# rpm -Uvh epel-release-5-4.noarch.rpm remi-release-5.rpm rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

CentOS 6 の場合

[root@ ~]# rpm -Uvh epel-release-6-7.noarch.rpm remi-release-6.rpm rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm


リポジトリが追加できたら、それぞれのリポジトリをいったん無効化します。
具体的に言うと、設定ファイルのenabledという項目を0に変更し、yum実行時に明示的に指定されない限り、新たに追加したリポジトリが利用されないようにします。
ちなみに、remiはもともとenabled=0となっているので、Fedora EPELとRPMForgeのみviコマンドで編集します。
※意図せず、標準外のリポジトリ(今回追加したリポジトリ)が使われないための対策です。

vi /etc/yum.repos.d/epel.repo

[epel]
name=Extra Packages for Enterprise Linux 5 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch
failovermethod=priority
enabled=0 ← 1を0に変更
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

vi /etc/yum.repos.d/rpmforge.repo

[rpmforge]
name = RHEL $releasever - RPMforge.net - dag
baseurl = http://apt.sw.be/redhat/el5/en/$basearch/rpmforge
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled=0 ← 1を0に変更
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

これでリポジトリの追加作業は完了です。

パッケージのインストール

それでは、パッケージのインストールを行います。
次のコマンド一発でインストールが開始され、途中で「y」を2回入力すれば、一気にLAMP環境を作られます。
今回は、追加したリポジトリが利用されるよう、--enablerepo オプションを付けています。

[root@ ~]# yum --enablerepo=remi,epel,rpmforge install httpd-devel php-devel php-pear mysql-server phpmyadmin -y
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile

・・略・・

Total download size: 42 M
Downloading Packages:

・・略・・

warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 00f97f56
remi/gpgkey | 1.3 kB 00:00
Importing GPG key 0x00F97F56 "Remi Collet " from /etc/pki/rpm-gpg/RPM-GPG-KEY-remi

Running rpm_check_debug

今回インストールしたモジュールを一覧にしました。

モジュールアーキテクチャバージョンリポジトリ
apr-develx86_641.2.7-11base
apr-util-develx86_641.2.7-11base
cyrus-sasl-develx86_642.1.22-5base
db4-develx86_644.3.29-10base
expat-develx86_641.95.8-8.3base
httpdx86_642.2.3-45base
httpd-develi3862.2.3-45base
httpd-develx86_642.2.3-45base
libeditx86_6420090923-3.0_1rpmforge
libmcryptx86_642.5.8-4extras
libtool-ltdlx86_641.5.22-7base
mysqlx86_645.5.11-1remi
mysql-libsx86_645.5.11-1remi
mysql-serverx86_645.5.11-1remi
mysqlclient15x86_645.0.67-1remi
openldap-develx86_642.3.43-12base
perl-DBD-MySQLx86_643.0007-2base
perl-DBIx86_641.52-2base
phpx86_645.3.6-3remi
php-clix86_645.3.6-3remi
php-commonx86_645.3.6-3remi
php-develx86_645.3.6-3remi
php-mbstringx86_645.3.6-3remi
php-mcryptx86_645.3.6-3remi
php-mysqlx86_645.3.6-3remi
php-pdox86_645.3.6-3remi
php-pearnoarch1.9.2-3remi
phpmyadmin.noarch2.11.11.3-1rpmforge

これで、インストールは完了です。


Apacheの設定 - モジュール編

それでは、Apacheの設定に移ります。
Apacheの設定は、/etc/httpd/conf/httpd.conf というファイルを編集して行いますが、モジュールの設定と、同時接続数の設定に分けて、順に見ていきましょう。

まずはモジュールの設定です。Apacheの場合、さまざまな機能を「モジュール」という形で用意しています。
モジュールを増やせばたくさんの機能を利用できますが、その反面メモリを大きく消費してしまうという問題があります。
CentOSのデフォルト状態では、ほぼ全てのモジュールが有効になっているため、必要以外のモジュールを除外する必要があります。

例えば、一切モジュールを消さないデフォルトの状態だと、1プロセスあたり5MB程度のメモリを消費していることが分かります。

#  ps aux|grep -v Ss|grep '[h]ttpd'|head -1
apache 22523 0.0 0.4 257548 5036 ? S 12:27 0:00 /usr/sbin/httpd

これを適切に設定しなおすと、4MB程度まで減らせます。
1プロセスあたり1MB省略できれば、200プロセスで200MB削減できることになりますし、実際にリクエストを受け付けているプロセスの場合はさらに消費メモリの差が出ることになります。

#  ps aux|grep -v Ss|grep '[h]ttpd'|head -1
apache 24715 0.0 0.4 161716 4228 ? S 19:46 0:00 /usr/sbin/httpd

とはいえ、どのモジュールが必要なのかが分かりにくいので、モジュールの一覧と、私の勝手な重要度をまとめました。
重要度は、◎、○、△、+、の4種類で分類しており、一覧にある重要度のタイトルをクリックすると、フィルターすることも可能です。
◎=必須
○=あったほうが良い
△=必要ならあればよい
+=必要性なし

モジュール名コメント
mod_auth_basicベーシック認証
mod_auth_digestダイジェスト認証
mod_authn_file認証にテキストファイルを利用する
いわゆる.htpasswdを使う場合は必要
mod_authn_alias
mod_authn_anon匿名ユーザを認証する
mod_authn_dbm認証にDBMファイルを利用する
mod_authn_default
mod_authz_hostホスト/IPアドレスでのアクセス制限
Orderや、Allow from ?? を使う場合は必須
mod_authz_userユーザ名でのアクセス制限
mod_authz_ownerファイル所有者でのアクセス制限
mod_authz_groupfileグループでのアクセス制限を行う(テキストファイル)
mod_authz_dbmグループでのアクセス制限を行う(DBMファイル)
mod_authz_default
mod_ldapLDAP用の基本モジュール
mod_authnz_ldapLDAPでのアクセス制限
mod_includeSSIを提供
SSIを利用する場合は有効にする
mod_log_configログ保存
アクセスログをとるためには必須
mod_logio送受信バイト数のログ保存(このモジュールがなければ保存できない)
mod_envCGIやSSIでの環境変数を設定する
必要なければ無効でかまわない
mod_ext_filterデータ返送時に外部プログラムを経由させる
mod_mime_magicファイルの内容をベースにMIMEタイプ決定
mod_expiresExpireヘッダをセットする
mod_deflateデータ返送時に圧縮する
mod_headersリクエスト、レスポンスヘッダを制御する
必要なければ無効でかまわない
mod_usertrackクッキーでユーザ追跡を行う
mod_setenvif環境変数の制御を行う
無効でもかまわないが、標準の設定ファイルで利用されており、有効にするのが無難
mod_mime拡張子をベースにMIMEタイプを決定
mod_davWebDAVを提供
mod_status/server-statusにてサーバ状態を表示する(URLは変更可能)
mod_autoindexディレクトリへのアクセス時にファイル一覧を作成する
mod_info/server-infoにてサーバ設定を表示する(URLは変更可能)
mod_dav_fsWebDAVを提供
mod_vhost_aliasバーチャルホストを簡単に生成
mod_negotiationクライアントに適したファイルを自動判別する(.jaなど)
mod_dirディレクトリの取り扱いを行う(index.htmlの取り扱いなど)
mod_actions特定の拡張子へのリクエストに応じてCGIを実行する
mod_speling大文字小文字を同じように扱えるようにする
mod_userdirユーザのホームディレクトにアクセスできるようにする(チルダ形式など)
mod_aliasAliasやRedirectを利用できるようにする
mod_rewriteRewrite機能を提供する
mod_proxyProxyを提供する
mod_proxy_balancerProxy時に負荷分散機能を提供
mod_proxy_ftpProxy時にFTP接続機能を提供
mod_proxy_httpProxy時にHTTP接続機能を提供
mod_proxy_connectProxy時にCONNECT機能を提供
mod_cacheキャッシュを提供
mod_suexecsuexecを提供
mod_disk_cachecache_moduleにおいて、ディスクキャッシュを提供
mod_file_cache静的ファイルをメモリにキャッシュさせる
mod_mem_cachecache_moduleにおいて、メモリキャッシュを提供
mod_cgiCGIを提供
mod_versionクライアントへのレスポンスにApacheバージョンを挿入する


※注意点
以下のモジュールを無効にすると、標準の設定ファイル(/etc/httpd/conf/httpd.conf)のまま起動するとエラーとなります。

  • mod_authz_hostを無効にした場合には、OrderやAllowなどの項目(例えば332行目など)をコメントアウトする必要があります
  • mod_proxyを無効にした場合には、以下ようにコマンドを実行し拡張設定ファイルを無効化する必要があります
  • # mv /etc/httpd/conf.d/proxy_ajp.conf /etc/httpd/conf.d/proxy_ajp.conf.stop
  • mod_autoindexを無効にした場合には、IndexOptionsから始まる関連項目(例えば592行目?657行目)を全てコメントアウトする必要があります
    もしくは以下のとおり、<IfModule>で括ってしまう方法もあります
  • vi /etc/httpd/conf/httpd.conf
    <IfModule mod_autoindex.c>
    IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable
    ・・略・・
    IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
    </IfModule>

ちなみに、私はいつも以下のモジュールを有効にしています。
なお、mod_autoindex と mod_proxy を無効化していますので、前述のとおり設定を変更しなければエラーとなって起動しません。

LoadModule authz_host_module modules/mod_authz_host.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule status_module modules/mod_status.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so


Apacheの設定 - 同時接続数編

それでは、Apacheの同時接続数の設定を見ていきましょう。
ここで基本を押さえておきたいのですが、Apacheにはpreforkとworkerという大きく分けると2つの方式があります。
preforkはサーバ1つ(1プロセス)で1つのリクエストを処理し、workerはサーバ1つで複数のリクエストを処理できます。
一見、workerのほうが良いように見えますが、workerはマルチスレッドで実装されていることから、ライブラリ全てがマルチスレッドに対応している必要があります。
ただ、PHPを使う場合にはライブラリ全てがマルチスレッド対応か否かを検証することは難しく、余計なトラブルを避けるためにもpreforkを利用するのが賢明であるといえます。
ということで、今回はpreforkを使う前提で説明を行います。

標準のhttpd.confでは、以下のように設定されています。

<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>

これらを順に見てみましょう。

  • StartServers
  • Apache開始時に立ち上げておくべきサーバ数。
    Apache起動直後は、ここで指定した数のサーバが立ち上がる。
  • MinSpareServers
  • アイドル中のサーバ数の下限。アイドル中とは、リクエストに対して即座に対応できる状態(つまり処理していない)のこと。
    ここで指定したサーバより少なくなった場合は、新たなサーバを立ち上げる。
    この数値が小さすぎると、急激にアクセスが増えたときに、リクエストに受けきれなくなる。
  • MaxSpareServers
  • アイドル中のサーバ数の上限。
    ここで指定したサーバより多くなった場合は、余計なサーバを終了させる。
    この数字が大きすぎると、アクセスが落ち着いている状態でもサーバが終了されず、メモリが無駄に消費されることになる。
  • ServerLimit
  • 後述するMaxClientsに指定できる数字の上限を指定する。
    MaxClientsを256より大きな数字にするとき以外は、特に変更の必要はない。
  • MaxClients
  • サーバ数の上限。
    ここで指定した数以上のサーバは立ち上がらない。
  • MaxRequestsPerChild
  • 処理できるリクエストの上限数。
    処理したリクエストがここで指定した数を超えると、該当サーバは終了される。

文字ではなかなかピンと来ない方も多いと思うので、グラフでまとめてみました。
このグラフでは見やすくするため、MaxClients 30、StartServers 10、MinSpareServers 5、MaxSpareServers 20としています。

apache-20110514.png

1起動直後であり、StartServersで指定された10サーバが立ち上がっている
210サーバが接続中でアイドル状態のサーバが0となったため、MinSpareServersに指定された5サーバが追加される
320サーバが接続中で上記と同じくアイドル状態サーバが0となったため、さらに5サーバが追加される
4アイドル状態のサーバが0になったものの、MaxClientsで指定された30サーバになったため、新規サーバは追加されない
5-7MaxClientsを超える数の接続がきたため、30の上限を超えるリクエストは、空きが出るまでまで待たされる
9-10アイドル状態のサーバ数は5以上20以下であり、新たなサーバの起動や、余剰サーバの終了処理は行わない
1130サーバがアイドル状態となったため、MaxSpareServersで指定された20サーバにすべく、10サーバが終了させられた


それでは、実際にどのような数字を設定すればいいか、考えて見ましょう。
一番重要なのはMaxClientsです。これが決まれば、上記の法則を見て他の値も決定してください。
たくさんのリクエストを受け付けるためには、大きな数値にすればよいと考えられがちですが、メモリやCPU能力が十分でなければ、むしろパフォーマンスが低下します。
経験則では、PHPを稼動させるApacheは1サーバあたり10MBから30MB程度のメモリを消費します。
例えば、Apacheで利用するメモリ容量を500MB程度に抑えたければ、20から40程度の数値にしておくのが無難です。

以下の例は、MaxClientsが256のときと、20のときで、どのように挙動が変わるかをabで図ったものです。

# ab -c 100 -n 2000 http://49.212.??.??/phpmyadmin/

MaxClientsが256の場合は、スワップを大きく消費しているほか、ロードアベレージも大きく上がっており、SSHのレスポンスについても非常に悪化していました。
それに対し20の場合は、それほど負荷の上昇は見られず、計測時間、秒間処理数、リクエストにかかる秒数の全てにおいて、改善していることが分かります。
要は、無理に同時に処理する数を増やすより、少々待たされる状態が出たとしてもサーバ能力を超えない範囲にしたほうが、結果としてレスポンスは良くなるということです。
サーバ負荷が高く、レスポンスが悪化した場合は、MaxClientsを増やすのではなく、減らすことをまず考えた方が賢明です。

MaxClientsスワップロードアベレージ計測時間秒間処理数リクエスト
256859MB79.2655.40秒36.10/秒2.73秒
2011MB5.4635.66秒56.08/秒1.74秒


1サーバあたりのメモリ使用量(ps結果のRSS)は10MB程度でしたので、100サーバだと1GB程度消費するのに対し、20サーバだと200MB程度で済みます。結局のところ、Apacheで使用する容量÷10MB?30MB程度で考えるのが良いでしょう。

参考までに、私が1GBメモリ、2コア程度のサーバ(さくらのVPS 1Gプラン相当)でいつも行っている設定は以下のような値です。

<IfModule prefork.c>
StartServers 10
MinSpareServers 5
MaxSpareServers 15
ServerLimit 256
MaxClients 40
MaxRequestsPerChild 1000
</IfModule>


Apacheの起動

Apacheを起動するには、serviceというコマンドを利用します。
以下のように打ち込んで、問題なければ正常に起動します。

# service httpd start
Starting httpd:                                            [ OK ]

なおエラーが出る場合には、モジュールを削ったときの設定ファイル変更を忘れている可能性があります。
設定ファイルの問題の際には、エラーメッセージとともに行番号が書かれていますので、再確認して下さい。


MySQLの設定と起動

それでは、MySQLの設定と起動を見てみましょう。
MySQLの設定については /etc/my.cnf を編集することで可能ですが、あらかじめ最低限の設定はされているので、ひとまず起動をして管理者パスワードの設定を行います。

MySQLを起動するには、serviceコマンドを利用します。

# service mysqld start
Initializing MySQL database:  Installing MySQL system tables...
OK
Filling help tables...
OK

・・中略・・

[ OK ]
Starting mysqld: [ OK ]

無事に起動できれば、[ OK ] と表示されます。

次に設定を移ります。
設定には専用のスクリプトが用意されているので、そちらを利用します。

# /usr/bin/mysql_secure_installation

・・略・・

Enter current password for root (enter for none): ← デフォルトではパスワードが無いので、そのままリターン
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

Set root password? [Y/n] y ← 「y」と入力してリターン
New password: ← rootパスワードとして設定したい文字列を入力してリターン
Re-enter new password: ← もう一度入力してリターン
Password updated successfully!
Reloading privilege tables..
... Success!


By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y ← 「y」と入力してリターン
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y ← 「y」と入力してリターン
... Success!

By default, MySQL comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y ← 「y」と入力してリターン
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y ← 「y」と入力してリターン
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

これで、MySQLが利用できるようになりました。


phpmyadminの設定

ここまでで、Apache、PHP、MySQLの全てが利用可能になりました。
最後に、phpmyadminの設定を行いましょう。

まずは、phpmyadminの設定ファイルを変更します。
変更するのは、blowfish_secret という項目だけです。以下のようにご自身で決めたランダムな文字列を入れてください。

vi /usr/share/phpmyadmin/config.inc.php

$cfg['blowfish_secret'] = 'dfj29jwIO1w19jjsdw219Ujdsjlk'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

次に接続元のIPアドレスを追加します。
以下のように、/etc/httpd/conf.d/phpmyadmin.conf を編集し、Allow from を追加します。

vi /etc/httpd/conf.d/phpmyadmin.conf

<Directory "/usr/share/phpmyadmin">
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
Allow from 59.106.??.??
</Directory>

設定ファイルの編集が終われば、Apacheに設定ファイルを再読み込みさせれば完了です。

# service httpd reload
Starting httpd:                                            [ OK ]

ブラウザからアクセスをすると、無事phpmyadminの画面が表示されました。
ユーザ名に root と入力し、パスワードには先ほどの文字列を入力します。

20110514-phpmyadmin.png


自動起動設定と、再起動

これで、LAMP環境の設定がひとまず完了し、利用可能な状況となりました。
しかし、これで安心してはいけません。
再起動した場合には、ApacheもMySQLも自動で起動せず、アクセスが受け付けられない状況となります。

自動起動するかどうかを確認するためには、chkconfigコマンドを利用します。
3という項目がoffの場合には、再起動時にApacheやMySQLが自動起動されません。

# chkconfig --list|grep -E "httpd|mysql"
httpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
mysqld          0:off   1:off   2:off   3:off   4:off   5:off   6:off
# chkconfig httpd on
# chkconfig mysqld on
# chkconfig --list|grep -E "httpd|mysql"
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
mysqld          0:off   1:off   2:on    3:on    4:on    5:on    6:off
#

これで再起動をすれば、全ての作業が完了です。
再起動しなくても問題ありませんが、再起動された時に自動で全てのソフトウェアが起動するかどうかを確かめるためにも、再起動を強くお勧めします

時間としては1時間程度で済みましたでしょうか?
最近では、クラウドの機能が増えたことによりこういった作業を必要ないという人もいますが、ウェブ開発者のたしなみとして、これくらいはできるべきだと思います。
慣れれば10分くらいでできますし、数十台程度であれば平行で作業すれば30分もあれば出来ます。

ということで、皆さんもぜひがんばってチャレンジしてみてください。
なお皆さまからも「ここはこの方がいい!」とかあればぜひご指摘頂ければ幸いです。

2012/5/7 CentOS 最新版に対応すべく修正しました。

さくらのVPSで上位プランに移行するための手順

  • 投稿日:
  • by
  • Category:

さて、本日からさくらのVPSの上位プランが提供開始されました。
昨年9月に980円で提供を開始した際には大変大きな反響を頂き、既に9,000件を超えるお客様にご利用頂いていますが、さらに高いスペックが欲しいというご意見に答えるため、8GBまでのハイスペックプランをご用意しました。

ただ、クラウド型IaaSと違って移行作業が必要という制限があるため、今回は上位プランへの移行方法をまとめてみました。

手順は以下のとおりです。

  1. DNSのTTLを60にします。(これは事前に余裕を持って行って下さい)
  2. 新旧両方のサーバにrsyncをインストールします。
  3. 旧サーバから新サーバへrsyncを使ってファイルをコピーします。
  4. 新サーバを再起動します。
  5. 旧サーバのhttpdやsendmailなどを停止します。(ここから7が完了するまでの間は外部からサーバ停止状態に見えます)
  6. もう一度、旧サーバから新サーバへrsyncを使ってファイルをコピーします。
  7. DNSのAレコードを新サーバに向けるとともに、TTLを元に戻します。
  8. 旧サーバの解約を行います。(毎月20日が解約締切りなので要注意)

それでは開始しましょう。
今回は、CentOSをベースに話をすすめますが、多くのOSで同じ手順が使えます。

移行作業にあたって
  • コピーにあたってはrootでログインする必要がありますので、sshの設定を適切に行って下さい
  • 新サーバと旧サーバのOSは、必ず同じものにしてください。
    古いサーバが32bit OSで、新しいサーバが64bit OSだと不具合が発生します。
  • 古いサーバと新しいサーバを絶対に間違えないようにして下さい。
    間違えると、全てのデータを失う可能性があります
  • さくらインターネットで正式サポートしているものではありません。
    自己責任で行っていただきますようお願い致します。

  1. DNSのTTLを60にします。

  2. サーバ切り替えに先立って、該当するホスト名のTTLを60に設定します。
    これは、実際に切り替えをするときに、即座に変更されるようにするためです。

    さくらインターネットのネームサーバにおける例は、以下のブログ記事を参照してください。

    さくらインターネットでDNSのTTLを変更する方法

    まず、変更したいドメイン(ホスト名)をdigコマンドで調べます。
    以下の例の場合は、TTLが3600に設定されているので、サーバ移転の3600秒前(1時間前)までに、この操作を行う必要があります。


    [root@localhost ~]# dig vps2.????.jp.

    ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> vps2.????.jp.
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62579
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;vps2.????.jp. IN A

    ;; ANSWER SECTION:
    vps2.????.jp. 3600 IN A 59.106.183.??

    ;; Query time: 3 msec
    ;; SERVER: 210.224.163.4#53(210.224.163.4)
    ;; WHEN: Mon Mar 7 20:09:25 2011
    ;; MSG SIZE rcvd: 47

    [root@localhost ~]#

    無事変更が出来れば、以下のとおりTTLが60になるのがわかります。


    ;; ANSWER SECTION:
    vps2.????.jp. 60 IN A 59.106.183.??

    ※自分のネームサーバでTTLが60になっていたとしても、他のネームサーバではキャッシュされたままの可能性があります。変更前のTTLで示された時間(上記の例だと3600秒間)は待つのが懸命です。

  3. rsyncのインストール

  4. 恐らく、さくらのVPSでのCentOSデフォルトではrsyncがインストールされていると思います。
    rsyncと入力してコマンドがなければ、yum install rsync とすれば結構です。

  5. ファイルのコピー

  6. 今回の手順では、サーバの停止時間を極力短くするために、旧サーバ停止前にコピーを行い、停止後に再度コピーを行うこととしています。
    2回目のコピーは差分だけですので、比較的短時間でコピーが完了します。

    コピーにはrsyncとsshを利用します。
    rsyncのオプションは以下のとおりです。

    オプション動作内容
    -rディレクトリ内容を再帰的にコピーします
    -t更新日時を保持します
    -lソフトリンクを保持します
    -z転送時に圧縮します
    -v饒舌になります
    -o所有者を保持します
    -gグループを保持します
    -pパーミッションを保持します
    -Hハードリンクを保持します
    -AACLを保持します
    -X拡張パーミッションを保持します
    --deleteファイルの削除を容認します
    --exclude除外するファイルの名前を指定します
    --block-size=チェックサムをとる際のブロックサイズを指定します
    -e sshssh経由でコピーします

    なお、今回のコピーにあたって、いくつかのファイルとディレクトリを除外しています。除外したファイルは、IPアドレスの設定を行なっているファイルと、sshのホストキーが含まれているファイル、そしてファイルシステムを指定しているファイルです。
    除外すべきファイルはOSによって異なりますので、ご注意下さい。


    # rsync -rtlzvogpHAX --delete --exclude /dev/ --exclude /proc/ --exclude /sys/ --exclude /var/run/ --exclude /var/lock/ --exclude ifcfg* --exclude ssh
    _host_* --exclude fstab --block-size=4096 -e ssh / 49.212.21.??:/
    root@49.212.21.??'s password:
    building file list ... done

    色々出てくる

    sent 2083607 bytes received 3212 bytes 379421.64 bytes/sec
    total size is 1705349185 speedup is 817.20

    これでコピーが完了しました。
    コピー時間は、どれだけのコンテンツやファイルがあるかにより、大きく変わります。

  7. 新サーバを再起動します。
  8. 新サーバを再起動すれば、古いサーバの設定を引き継いだ形で動作を開始するはずです。

  9. 旧サーバのhttpdやsendmailなどを停止します。
  10. 旧サーバで動作している全てのサービスを停止させます。
    例えば、httpdやsendmail、mysql-serverなどのことです。
    service httpd stop などと入力して、停止させましょう。

    この時点で、外部の人はこのサーバへアクセスできなくなります。

  11. もう一度、旧サーバから新サーバへrsyncを使ってファイルをコピーします。
  12. 旧サーバがサービスを停止したことを確認して、再度コピーを行います。
    2回目なので、さほど時間はかからないと思います。


    # rsync -rtlzvogpHAX --delete --exclude /dev/ --exclude /proc/ --exclude /sys/ --exclude /var/run/ --exclude /var/lock/ --exclude ifcfg* --exclude ssh
    _host_* --exclude fstab --block-size=4096 -e ssh / 49.212.21.??:/
    root@49.212.21.??'s password:
    building file list ... done

    色々出てくる

    sent 2096209 bytes received 920 bytes 220750.42 bytes/sec
    total size is 1705349185 speedup is 813.18

  13. DNSのAレコードを新サーバに向けるとともに、TTLを元に戻します。
  14. 新しいサーバに向けてIPアドレスを変更します。
    それと同時に、先ほど60にしたTTLをもとに戻します。

    ※TTLが60のままだと、キャッシュがされないためにサイトへのアクセスが非常に遅くなります。

    この作業が完了して60秒以上経てば、外部から新サーバへのアクセスが可能になります。

  15. 旧サーバの解約を行います。(毎月20日が解約締切りなので要注意)
  16. 数日間状況を見て、旧サーバの解約を行います。
    なお、さくらインターネットの場合には、解約前月の20日までに解約申請をしなければなりません。
    例えば、3月20日までに解約申請すれば4月末での解約となりますが、これを過ぎると1ヶ月間無駄に支払わなければならなくなるので注意してください。

以上が移行手順です。

是非皆様も上位プランで充実したVPSライフをお送り下さい。

格安の低価格VPSを比較する

  • 投稿日:
  • by
  • Category:

最近、IaaS型クラウドの流行の裏で、VPSがひそかな人気を集めています。
VPSは、クラウドのような従量課金やAPIアクセス、柔軟なリソース増減はできませんが、その分安価な価格設定が行われることが多く、数ヶ月以上利用するのであればクラウドよりも非常に安価で高いパフォーマンスを得られることが特徴です。
また、コントロールパネルで起動、停止、再起動などの操作や、OS再インストールなど、クラウドで言うところの「セルフサービスによる」という部分は多くのVPSで実現されており、さくらのVPSに限ってはコンソールをホストOS経由で直接アクセスできるなど、物理サーバの置き換え用途としても十分に利用できる内容となってきました。
さらに、申し込みから利用開始まで数分から数十分程度で行えるなど、従量課金ではないことと解約が手動となる点を除けばIaaS型クラウドに決して劣るものではありません。

ただ、たくさんのVPSが各社から提供され、なかなか選べないよという方も多いのが実情です。
今回は、さくらのVPSのほか、話題を呼んでいる日本ラッドさんのSaaSes Osukini Serverと、DTIさんのServersman@VPSを取り上げ、それぞれのVPSについて比較をしてみました。
いちおう公平に書くようにしましたが、色眼鏡で見ていただいても結構です。m(_ _)m

それでははじめに各社の仕様をまとめてみます。

プラン名 さくらのVPS Osukini Server Serversman@VPS
512 1G 1.5G 4G 8G LT ST GT XT Entry Standard Pro
初期費用(円) 0 2,980 4,980 9,980 19,980 6,000 6,000 10,000 14,000 0 0 0
月額(円) 980 1,480 1,980 3,980 7,980 450 980 1,980 4,980 490 980 1,980
年払い割引 1か月分割引 なし なし
試用期間 2週間 2週間 記載なし
(キャンペーン対応)
メモリ容量 512MB 1GB 1.5GB 4GB 8GB 512MB 1GB 2GB 4GB 256MB 512MB 1GB
HDD容量 20GB 30GB 50GB 120GB 240GB 50GB 100GB 200GB 400GB 10GB 30GB 50GB
SWAP設定 ×
リモート
コンソール
× ×
固定IP v4
v6 × ×
追加IP ×
月額500円
×
1個

3個
IP逆引き
制限あり
仮想化プラットフォーム KVM完全仮想化 Xen完全仮想化 OpenVZコンテナ
OS CentOS
Debian
Ubuntu
Fedora × ×
FreeBSD × ×
現在のキャンペーン
今なら初期費用半額 今なら最大2か月分を無料に
その他の制約等 試用期間中は2Mbps制限
試用期間中はOP25Bあり

VPN設定不可
iptablesエントリ数の上限あり
※Serversman@VPSは、ウェブサイト上にて最大メモリの表記がありますが、あくまでも保障メモリで比較しています。


これではわかりにくいので、一番の関心事であろう価格について、それぞれ初年度にいくらかかるかを比較してみましょう。
また、メモリ1MBあたりの単価、HDD 1GBあたりの単価も見てみます。

プラン名 さくらのVPS Osukini Server Serversman@VPS
512 1G 1.5G 4G 8G LT ST GT XT Entry Standard Pro
年間の利用額(円) 10,780 19,260 26,760 53,760 107,760 11,400 17,760 33,760 73,760 5,880 11,760 23,760
メモリ1MBあたり(円) 21.0 18.8 17.4 13.1 13.2 22.3 17.3 16.5 18.0 23.0 23.0 23.2
HDD 1GBあたり(円) 539.0 642.0 535.2 448.0 449.0 228.0 177.6 168.8 184.4 588.0 392.0 475.2


ここで、グラフ化してそれぞれのプランがどのような位置にあるのかを見てみます。
まず、メモリの容量を横軸にした価格帯です。
VPS価格比較
導入費用が絶対価格で最も安いのはServersman@VPSのEntryプランですが、概ね価格帯は似通っているといえます。
低スペック帯では唯一256MBモデルを出しているServersman@VPSが安価であり、512MBあたりでは3社とも同様の価格となり、高スペック帯ではさくらのVPSがもっとも安価ということがわかります。

次に、HDD容量を横軸にした価格帯を見てみましょう。
VPS価格比較
総じていえるのは、Osukini Serverが飛びぬけて大容量であるということでしょう。
例えば、1万円の場合にさくらのVPSは20GB、Serversman@VPSは30GBのところ、Osukini Serverは50GBと大幅に大きいことがわかります。

ちなみに、キャンペーン適用した価格はどうなのか?1年を超えると結果は違うのでは?との質問もあったので、いちおうグラフを作りました。正直なところずっとキャンペーンをしている事業者は不公正だし信用できないので加味する必要性を全く感じませんが、信頼性がないとか言われても嫌なので参考までに。

結果的には大して変わりませんでした。
結局、低スペック帯ではServersman@VPSが価格優位なこと、SaaSesが価格に対してHDDが大容量なこと、高スペック帯ではさくらのVPSが価格優位なこと、それぞれ変わることはありません。
ただ、Serversman@VPSは期間が長くなると価格メリットが薄れてくるようです。

それでは気をとりなおして、最後にベンチマーク比較を見てみましょう。
既にこれらのVPSサービスの利用者の方がunixbenchで計測されていますので、その情報を見てみたいと思います。
それぞれ、「さくらのVPS unixbench」「Saases unixbench」「serversman unixbench」とGoogleで検索して出てきたページから抜粋しています。

VPS性能比較
これを見ると、さくらのVPSが1200から1500程度、Serversman@VPSがEntryで200から400程度、Standardで400?800程度で、Osukini ServerがLTとSTともに600程度です。
unixbenchだけでは結果はわかりませんが、数字を見る限りさくらのVPSが飛びぬけて性能がよいのは間違いなさそうです。

ただ、性能だけを見ても仕方が無いので、価格性能比をマッピングしてみましょう。
VPS性能比較
やはり性能についてはさくらのVPSが良いですが、興味が惹かれるのはServersman@VPSです。Osukini Serverが価格が上がっても性能が変わらないのに対し、Serversman@VPSはプランごとに性能が変わっているうえ、TurboモードをONにすることによる性能の向上が見られます。
完全仮想化の場合はゲスト空間が利用者に全て委ねられるのに対し、OpenVZの場合はCPU性能をコントロール出来るというのが寄与しているものと思われます。

それでは、ここでまとめにしたいと思います。
比較を実際にしてわかったのは、各社各様に特徴があるなというところで、本当はさくらのVPSを推したいところですが、そうは甘くないようです。
ということで各社の特徴をまとめてみました。

  • さくらのVPS
    • 高スペックプランになるほど、コストパフォーマンスがよくなる
    • リモートコンソールが利用できる
    • サーバ性能が飛びぬけて良い
    • 利用できるOSが多い
    • 初期費用が無い(980プランのみ)
  • Osukini Server
    • HDD容量が飛びぬけて大きい
  • Serversman@VPS
    • IPv6が利用できる
    • IPv4が複数利用できる(StandardとProのみ)
    • 低スペックプランがラインナップされ、最も安い
      (過去のキャンペーン適用者で、Entryを月105円で利用できてる人もいるらしい)
    • 運が良ければ保障以上のメモリを使える(但しプロセスがしばしばkillされる)
    • 初期費用が無い

私の結論としては、

  • スペックや性能が低くてもとにかく安くということでは、Serversman@VPS
  • HDD容量が欲しければ、Osukini Server
  • HDD容量はそこそこで良く、月に980円以上出せるのであれば、さくらのVPS
というところでしょうか。

なお上述のとおり、ある程度の値段になると、Osukini Serverか、さくらのVPSという選択肢しかなく、スワップが利用できることも考えると、本格運用の場合には Osukini Server か、さくらのVPSの2択かなと思います。
本当はさくらのVPSだけを推したいところでしたが、さすが岡田さんだけあってOsukini Serverも良くできているという印象です。

また今後、Amazon Web Servicesや、Linodeなども取り上げる予定ですが、皆さんからもご意見などいただければ幸いです。

さくらのVPS提供開始にあたり

  • 投稿日:
  • by
  • Category:

本日より、さくらインターネットの新しい柱となる仮想化サービスの第一号として、さくらのVPSを販売開始することとなりました。

さくらのVPS お申し込み受付開始のお知らせ

皆様からは「えっさくらがVPSをやるの?」という声も多く頂いており、その反響の大きさに驚いています。
そもそも、昨年あった@ITの取材においては「劣化専用サーバとなるVPSはやらない」と豪語しており、同業者の会合でも「さくらはVPSやらない」と宣言していました。

大阪・堂島に、さくらインターネットの秘密を見た ?自前だからできる本当の差別化
http://www.atmarkit.co.jp/ad/sakurainet/200905/doujima.html

その理由としては、仮想化を行うより、専用サーバでとことん安くしたほうが良いのではないかという考えがあります。
コンソール機能や再起動などはIPMI(Keyboard VGA Mouse = KVM)によって専用サーバでも実現できますし、さくらの専用サーバについては、翌営業日納品も実現していますから、仮想サーバで無いとできないと思われていることも実現が進んできています。
また、仮想化することはオーバーヘッドを生むことにもつながり、CPUパワー度無駄にする側面もあります。

しかし、仮想化には代えがたい優位性があることも事実です。
例えば、専用サーバアドバンスドプランのQuadCore Xeon×2CPU構成の場合、初期費用無料で月額35,800円ですが、仮想化して8分割すれば1コアあたり4,475円となります。低価格専用サーバはAtom Z530を4,500円程度+初期費用で提供予定でしたが、ATOMの1コアとXeonの1コアだと仮想化のオーバーヘッドを考えてもXeonのほうが高速であり、さらには安価に提供できるという状況になってしまいます。
私自身がやっている某サイト(とある櫻花の画像生成)においても、データベースやリバースプロキシ、画像配信などを、仮想化を使って複数のサーバに分けて運用することにより、アクセス急増時も効率よくサーバ運営が出来たという経験があり、比較的安価にサーバ分割が出来る仮想化の利便性を知ることになりました。

結局、既存形態のサービスに固執するがあまり、さくらインターネットが本来強みとしていたITリテラシの高いユーザへのサービスへの魅力が薄れ、そのようなユーザが海外のクラウドや格安VPSへ流出し始める状況に至ります。

このような事から、仮想化の推進を行い、さらにVPSやIaaSへの拡大を進めていくことを決断し、第一号としてさくらのVPSを提供開始することとなりました。
4月末に「VPSやるぞ。でも全て自社開発で」と突然言い出してから、2カ月程度でベータ提供にこぎつけたのは社員の頑張りのおかげでもあり、大変感謝しています。
今後は、専用サーバのさらなるスペックアップと並行して、仮想化による柔軟性や手軽さを追求したサービスを拡大していきます。

なお、さくらのVPSの登場で既存の専用サーバが売れなくなるのではという意見もあります。
この意見については当然の事ですし確かに大きな影響があると考えていますが、今回のVPSを始めるにあたってはそのような影響を一切無視してサービスづくりを行いました。
専用サーバが売れなくなるのであれば、それは専用サーバの魅力が薄れていただけの話であり、その様なサービスは遅かれ早かれ他社(または海外)に駆逐されるだけだと考えています。

先にシェアを取っている会社は常に既存の売り上げとのバランスを考えがちです。
しかし、さくらのレンタルサーバにしても、専用サーバプラットフォームSTにしても、常に既存の売り上げに固執せず、新しい柱を創ることへ注力してきました。
ですので、今後も性能、品質、サポート、価格など全ての面に妥協することなく、さくららしいサービスを創っていくことを皆さんにお約束します。

ところで、さくらインターネットでは石狩へのデータセンター建設を進めております。
クラウド化する中で、インフラのコストパフォーマンスはさらに重要になってきており、高いコストパフォーマンスを実現できる理由としてのインフラ追求はますます必要です。
しかしながら、重要なのはインフラだけでなく上に乗るサービス自身もだと考えています。
今後は、インフラに、サービスに、全てのレイヤーを自前で行えるという強みを伸ばし、さらなるサービス拡充に努めてまいりますので、今後ともよろしくお願いいたします。

「さくらのVPS」を使ってみる

  • 投稿日:
  • by
  • Category:

先日、「さくらのVPS」のベータテストが開始されました。
私も個人的にさくらのレンタルサーバを利用しているので、7月14日にフライングして申し込みしました。
(最終テスト中だったようで、社員にまじめに怒られてしまいましたが・・。スイマセン)

まず基本仕様


  • CPU 2コア

  • メモリー 512MB

  • HDD 20GB

  • ネットワーク 100Mbps(いちおうの上限)

  • リモートコンソール付き

  • 再起動、再インストールは、セルフサービスでコンパネから可能

ホスト側は、QuadCore Xeonで、1Gbpsにて上位スイッチに接続し、10Gbpsでさくらインターネットの基幹ネットワークに接続しています。
(クローズドベータテスト中に400Mbps位出たという記事もありましたが、さすがに対策する予定です)

ハイパーバイザーは、巷の格安VPSで多く利用される、VirtuaozzoやOpenVZ、Xenの準仮想化と異なり、KVMで完全仮想化になっています。
完全に512MBの実メモリを割当しますから、ホストOS側でスワップされずパフォーマンスが低下しないですし、ゲスト環境側でスワップを用意することも可能です。

実メモリは、ゲストで必要とするメモリ容量の1.5倍?2倍程度を搭載しています。
というのは、ホストOSのメモリの2/3以上をゲストに割り当てると、過負荷時のレスポンスが急激に悪化したり、不安定になったりということが言われており、当社でも再現されているので、余裕を持った設計にしています。
さらに、ホストOSのメモリの余裕を持たすことで、ディスクI/Oも劇的によくなります。
ゲストOSのスワップ時でも、ホストOSのキャッシュに入っていれば、メモリの延長上といえるかもしれません。

このように、100Mbpsインターフェース、20GBのHDD、2 CPU、512MBメモリといっても、同種のVPSサービスとは一線を画します。
その上で、「格安VPS」といえる価格帯で出す予定にしていますので、海外にも増してメリットのあるサービスになるのではと考えています。


と、宣伝はここまでにして、早速利用してみます。


まず、私が行ったのは、sshの公開鍵を設置してrootログインできないようにすることです。
申し込み直後は、ほぼ最新のパッチを当てて出荷されますので、いきなりクラックされることは考えなくてもよいと思いますが、なんとなく不安です。
(対策として、ネットワークをシャットダウンしたまま出荷するオプションを用意するなど、検討の余地があると考えています。)

ということで、ssh-keygenを行い、/etc/ssh/sshd_configにrootでのパスワードログインを禁止します。

[root@www10xxu ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
1b:f0: root@www10xxu.sakura.ne.jp
[root@www10xxu ~]#
/etc/ssh/sshd_config
変更前
PermitRootLogin yes
変更後
PermitRootLogin without-password
[root@www10xxu ~]# service sshd restart


次に無駄なデーモンをoffにします。
さくらのVPSの初期状態において脊髄反射で感じるのは「思いのほか空きメモリが少ない!」ということです。

ps -aux結果

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  10348   688 ?        Ss   Jul15   0:00 init [3]
root         2  0.0  0.0      0     0 ?        S<   Jul15   0:03 [migration/0]
root         3  0.0  0.0      0     0 ?        SN   Jul15   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S<   Jul15   0:00 [watchdog/0]
root         5  0.0  0.0      0     0 ?        S<   Jul15   0:01 [migration/1]
root         6  0.0  0.0      0     0 ?        SN   Jul15   0:00 [ksoftirqd/1]
root         7  0.0  0.0      0     0 ?        S<   Jul15   0:00 [watchdog/1]
root         8  0.0  0.0      0     0 ?        S<   Jul15   0:00 [events/0]
root         9  0.0  0.0      0     0 ?        S<   Jul15   0:00 [events/1]
root        10  0.0  0.0      0     0 ?        S<   Jul15   0:00 [khelper]
root        15  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kthread]
root        20  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kblockd/0]
root        21  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kblockd/1]
root        22  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kacpid]
root        90  0.0  0.0      0     0 ?        S<   Jul15   0:00 [cqueue/0]
root        91  0.0  0.0      0     0 ?        S<   Jul15   0:00 [cqueue/1]
root        94  0.0  0.0      0     0 ?        S<   Jul15   0:00 [khubd]
root        96  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kseriod]
root       168  0.0  0.0      0     0 ?        S    Jul15   0:00 [khungtaskd]
root       169  0.0  0.0      0     0 ?        S    Jul15   0:00 [pdflush]
root       170  0.0  0.0      0     0 ?        S    Jul15   0:00 [pdflush]
root       171  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kswapd0]
root       172  0.0  0.0      0     0 ?        S<   Jul15   0:00 [aio/0]
root       173  0.0  0.0      0     0 ?        S<   Jul15   0:00 [aio/1]
root       317  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kpsmoused]
root       361  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata/0]
root       362  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata/1]
root       363  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata_aux]
root       373  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kstriped]
root       386  0.0  0.0      0     0 ?        S<   Jul15   0:04 [kjournald]
root       407  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kauditd]
root       435  0.0  0.1  12672   764 ?        S<s  Jul15   0:00 /sbin/udevd -d
root      1059  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kmpathd/0]
root      1060  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kmpathd/1]
root      1062  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kmpath_handlerd]
root      1112  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kjournald]
root      1429  0.0  0.1   5908   608 ?        Ss   Jul15   0:00 syslogd -m 0
root      1432  0.0  0.0   3804   424 ?        Ss   Jul15   0:00 klogd -x
dbus      1492  0.0  0.1  21256   964 ?        Ss   Jul15   0:00 dbus-daemon --system
root      1501  0.0  0.1   3800   580 ?        Ss   Jul15   0:00 /usr/sbin/acpid
68        1509  0.0  0.7  30604  3660 ?        Ss   Jul15   0:00 hald
root      1510  0.0  0.2  21692  1056 ?        S    Jul15   0:00 hald-runner
68        1518  0.0  0.1  12324   844 ?        S    Jul15   0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
68        1523  0.0  0.1  12324   848 ?        S    Jul15   0:00 hald-addon-keyboard: listening on /dev/input/event0
root      1532  0.1  0.1  10228   680 ?        S    Jul15   4:09 hald-addon-storage: polling /dev/hdc
root      1547  0.0  0.2  62624  1208 ?        Ss   Jul15   0:00 /usr/sbin/sshd
ntp       1558  0.0  0.9  23388  5028 ?        SLs  Jul15   0:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
root      1576  0.0  0.4  69004  2348 ?        Ss   Jul15   0:00 sendmail: accepting connections
smmsp     1584  0.0  0.3  59764  1800 ?        Ss   Jul15   0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root      1593  0.0  0.2  19708  1144 ?        Ss   Jul15   0:00 crond
root      1601  0.0  0.0  18732   456 ?        Ss   Jul15   0:00 /usr/sbin/atd
root      1615  0.0  0.2  52108  1332 ?        Ss   Jul15   0:00 login -- root
root      1616  0.0  0.0   3792   480 tty2     Ss+  Jul15   0:00 /sbin/mingetty tty2
root      1617  0.0  0.0   3792   484 tty3     Ss+  Jul15   0:00 /sbin/mingetty tty3
root      1628  0.0  0.0   3792   480 tty4     Ss+  Jul15   0:00 /sbin/mingetty tty4
root      1629  0.0  0.0   3792   480 tty5     Ss+  Jul15   0:00 /sbin/mingetty tty5
root      1640  0.0  0.0   3792   480 tty6     Ss+  Jul15   0:00 /sbin/mingetty tty6
root      1641  0.0  0.1   3800   536 ttyS0    Ss+  Jul15   0:00 /sbin/agetty -h 115200 ttyS0 vt100
root      1684  0.0  3.1 201952 15920 ?        SN   Jul15   0:00 /usr/bin/python -tt /usr/sbin/yum-updatesd
root      1686  0.0  0.2  12916  1160 ?        SN   Jul15   0:00 /usr/libexec/gam_server
root      1722  0.0  0.6  90320  3528 ?        Ss   Jul15   0:00 sshd: root@pts/0
root      1724  0.0  0.2  10932  1440 pts/0    Ss+  Jul15   0:00 -bash
root      1758  0.0  0.2  10928  1372 tty1     Ss+  Jul15   0:00 -bash
root     10606  0.0  0.6  91048  3380 ?        Rs   13:17   0:00 sshd: root@pts/1
root     10608  0.0  0.2  10932  1392 pts/1    Ss   13:17   0:00 -bash
root     10643  0.0  0.1  10460   876 pts/1    R+   13:38   0:00 ps -aux

まず、コンソール(mingetty)はこんなに要らないので、減らします。

/etc/inittabを以下のように編集


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
#2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

デーモンも減らします。

[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig haldaemon off
[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig acpid off
[root@www10xxu ~]# chkconfig messagebus off

これで再起動すれば、ずいぶんとメモリの空きができます。
再起動後に確認すると、使用中は150MBとなっていました。もう少しがんばれば、もっと削減できそうです。


なお、unixbenchも実行してみました。
index scoreは1540.6ですので、そこそこ速いのではないでしょうか。

   #    #  #    #  #  #    #          #####   ######  #    #   ####   #    #
   #    #  ##   #  #   #  #           #    #  #       ##   #  #    #  #    #
   #    #  # #  #  #    ##            #####   #####   # #  #  #       ######
   #    #  #  # #  #    ##            #    #  #       #  # #  #       #    #
   #    #  #   ##  #   #  #           #    #  #       #   ##  #    #  #    #
    ####   #    #  #  #    #          #####   ######  #    #   ####   #    #

Version 5.1.2 Based on the Byte Magazine Unix Benchmark

Multi-CPU version Version 5 revisions by Ian Smith,
Sunnyvale, CA, USA
December 22, 2007 johantheghost at yahoo period com


1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10

1 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10

1 x Execl Throughput 1 2 3

1 x File Copy 1024 bufsize 2000 maxblocks 1 2 3

1 x File Copy 256 bufsize 500 maxblocks 1 2 3

1 x File Copy 4096 bufsize 8000 maxblocks 1 2 3

1 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10

1 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10

1 x Process Creation 1 2 3

1 x System Call Overhead 1 2 3 4 5 6 7 8 9 10

1 x Shell Scripts (1 concurrent) 1 2 3

1 x Shell Scripts (8 concurrent) 1 2 3

2 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10

2 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10

2 x Execl Throughput 1 2 3

2 x File Copy 1024 bufsize 2000 maxblocks 1 2 3

2 x File Copy 256 bufsize 500 maxblocks 1 2 3

2 x File Copy 4096 bufsize 8000 maxblocks 1 2 3

2 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10

2 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10

2 x Process Creation 1 2 3

2 x System Call Overhead 1 2 3 4 5 6 7 8 9 10

2 x Shell Scripts (1 concurrent) 1 2 3

2 x Shell Scripts (8 concurrent) 1 2 3

========================================================================
BYTE UNIX Benchmarks (Version 5.1.2)

System: www1010u.sakura.ne.jp: GNU/Linux
OS: GNU/Linux -- 2.6.18-194.8.1.el5 -- #1 SMP Thu Jul 1 19:04:48 EDT 2010
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5319.4 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
CPU 1: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5290.9 bogomips)
x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
10:15:43 up 1 day, 19:18, 2 users, load average: 0.02, 0.02, 0.00; runlevel 3

------------------------------------------------------------------------
Benchmark Run: Sat Jul 17 2010 10:15:43 - 10:43:56
2 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 14188657.9 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3011.2 MWIPS (9.8 s, 7 samples)
Execl Throughput 1775.5 lps (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 709457.6 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 210832.6 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1449865.3 KBps (30.0 s, 2 samples)
Pipe Throughput 1955338.6 lps (10.0 s, 7 samples)
Pipe-based Context Switching 259909.8 lps (10.0 s, 7 samples)
Process Creation 8795.8 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 4125.4 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 1416.6 lpm (60.0 s, 2 samples)
System Call Overhead 3385128.4 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 14188657.9 1215.8
Double-Precision Whetstone 55.0 3011.2 547.5
Execl Throughput 43.0 1775.5 412.9
File Copy 1024 bufsize 2000 maxblocks 3960.0 709457.6 1791.6
File Copy 256 bufsize 500 maxblocks 1655.0 210832.6 1273.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 1449865.3 2499.8
Pipe Throughput 12440.0 1955338.6 1571.8
Pipe-based Context Switching 4000.0 259909.8 649.8
Process Creation 126.0 8795.8 698.1
Shell Scripts (1 concurrent) 42.4 4125.4 973.0
Shell Scripts (8 concurrent) 6.0 1416.6 2361.0
System Call Overhead 15000.0 3385128.4 2256.8
========
System Benchmarks Index Score 1157.7

------------------------------------------------------------------------
Benchmark Run: Sat Jul 17 2010 10:43:56 - 11:12:10
2 CPUs in system; running 2 parallel copies of tests

Dhrystone 2 using register variables 27985122.2 lps (10.0 s, 7 samples)
Double-Precision Whetstone 5992.4 MWIPS (9.7 s, 7 samples)
Execl Throughput 7332.5 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 218518.6 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 63801.8 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 502186.1 KBps (30.0 s, 2 samples)
Pipe Throughput 3771938.1 lps (10.0 s, 7 samples)
Pipe-based Context Switching 775819.3 lps (10.0 s, 7 samples)
Process Creation 20049.5 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 9979.2 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 1579.2 lpm (60.0 s, 2 samples)
System Call Overhead 5635202.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 27985122.2 2398.0
Double-Precision Whetstone 55.0 5992.4 1089.5
Execl Throughput 43.0 7332.5 1705.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 218518.6 551.8
File Copy 256 bufsize 500 maxblocks 1655.0 63801.8 385.5
File Copy 4096 bufsize 8000 maxblocks 5800.0 502186.1 865.8
Pipe Throughput 12440.0 3771938.1 3032.1
Pipe-based Context Switching 4000.0 775819.3 1939.5
Process Creation 126.0 20049.5 1591.2
Shell Scripts (1 concurrent) 42.4 9979.2 2353.6
Shell Scripts (8 concurrent) 6.0 1579.2 2632.1
System Call Overhead 15000.0 5635202.3 3756.8
========
System Benchmarks Index Score 1540.6

と、雑多にまとめてみました。

なお、ただいまベータテスト中で、追加予定機能は山のようにあるので、状況を見ながらアップデートして行きたと思います。
ツイッターでもさまざまな要望を頂いていますが、ぜひ参考にさせていただきたいので、コンパネ上の「ご意見・ご要望」もご活用ください。

「さくらのVPS」はじまります

  • 投稿日:
  • by
  • Category:

バレンタインデーのラックチョコ以来、ずいぶん更新をサボってしまいましてすいません。

最近、ツイッターで意見や感想を吐き出してしまうので、なかなかブログの更新ができておりませんでした。
どうも、考えが成熟する前に、小出しでつぶやいてしまうのがアカンです。
ブログで書くからウェブサイト更新をしなくなり、ツイッターでつぶやくからブログを書かなくなり、次はどうなるのでしょうか・・。

さて、さくらインターネットでは9月より「さくらのVPS」と称してVPS(仮想専用サーバ)サービスを始めることを発表し、さる7月15日よりクローズドベータテストを開始することになりました。
ただ、十分だろうと考えていた200ユーザ(急遽300ユーザに拡大)の枠があっという間にいっぱいになってしまい、すべての方に試用頂けていないことを深くお詫びいたします。
ついては、ベータテストのユーザ数を増やすべく、サーバーやラック、ネットワークの準備を進めることにしましたので、8月初旬より追加で募集が可能な見込みです。

今回のVPSを開始するにあたり、社内外から「さくらはVPSやらないんじゃなかったっけ?」という話をいただきました。
とある記事では、「劣化専用サーバとしてのVPSには競争力はない」などと豪語し、周りからは「さくらはVPSをやらない」と言われてきましたが、サーバ再起動やOS再インストール、コンソールといった、VPSならではの管理機能を搭載してリリースすることにしました。
今後、専用サーバにIPMIを搭載して、VPS同様に管理機能をサポートする予定であり、ハイスペックな専用サーバと、リーズナブルなVPSをハイブリッドで提供していくことにしています。
併せて時間課金などのシステム強化を行い、仮想サーバをベースとしたIaaSや、KVSなどのPaaSを拡大させて、さくらインターネットらしいクラウドサービスにしていく予定にしています。

さくらインターネットでは、先日発表した石狩データセンターによって米国と同様のコスト構造を手に入れるとともに、上記のようなクラウドサービスによるサービスの柔軟性を達成したいと考えています。
また、東京都心の1,000ラック以上を活用し、クラウド、ホスティング、ハウジングのハイブリッドサービスを追及していく予定です。
これらによって、海外にも通用し、日本国内においてはさらに優位性を発揮できる強いさくらインターネットを作り上げていきます。