さくらのVPS SSDプランのメモリが、お値段そのままで倍に

  • 投稿日:
  • by

本日より、さくらのVPS SSDプランのメモリが、お値段そのままで倍の容量になりました。
新規に申し込みされる方はもちろんのこと、すでに契約頂いたサーバについても倍の容量になります。
これに伴うホストサーバ側でのメンテナンスはなく、お客様の都合に合わせてシャットダウン&起動を行って頂くだけで、メモリが倍になります。
というのも、もともとSSDじゃないプランに比べて倍のメモリを積んでいたのですが、半年以上の安定したSSD運用を受けて、お客様の利用できるメモリ容量を倍にすることになりました。

ちなみに、SSDじゃないプランの場合は2GBで1,480円/月、4GBで3,980円/月ですが、SSDプランの場合だと2GBで1,780円、4GBで3,680円と、SSDプランのコストパフォーマンスが非常によくなりました。
もちろん、SSDプランの場合はディスクの容量が少ないというのがネックですが、それでも50GBもしくは100GBと、データベース用途程度であればそれほど苦のないスペックかと思います。

ということで、私も個人で借りているSSDプランをグレードアップしたのでその手順を貼っておきます。

まず、シャットダウンする前のメモリ容量を確認。
totalが、1922676バイトですので2GBであることが分かります。

[root@db1 mysql]# free
             total       used       free     shared    buffers     cached
Mem:       1922676    1853092      69584          0      31632    1295388
-/+ buffers/cache:     526072    1396604
Swap:      2097144      25124    2072020


これからシャットダウンをしますが、あらかじめVPSコントロールパネルにログインしておきます。
ちなみに、VPSコントロールパネルにおいては、すでにメモリ容量は倍の表示になっていますが、実際にはシャットダウンしないと倍増しません。
ということで、VPSコントロールパネルへのログインができれば、コマンドラインからシャットダウンを行います。

[root@db1 mysql]# shutdown -h now

Broadcast message from root@db1.myapp.jp
(/dev/pts/0) at 15:16 ...

The system is going down for halt NOW!


シャットダウンが完了すると、VPSコントロールパネルにおいて「停止」というステータスになります。
「稼働中」になっている場合は、「更新」というボタンをクリックしてください。
停止していることが確認できれば、「起動」というボタンをクリックしてください。

VPSコントロールパネル

再起動が終わってからサーバへログインすると、メモリの容量が3923048バイトになり、4GBへ倍増されたことが分かります。

[root@db1 ~]# free
             total       used       free     shared    buffers     cached
Mem:       3923048     137672    3785376          0       6116      28116
-/+ buffers/cache:     103440    3819608
Swap:      2097144          0    2097144


ところで、このサーバはとある科学のレールガンや進撃の巨人などのロゴジェネレーターをつくるサイトのメタデータを保存しているサーバなのですが、MySQLの自動起動を忘れていて数分ほどサイトを止めてしまいました。
皆さんも、デーモンが自動起動する設定にしているかどうか、良く確認してから作業して下さいね。

[root@db1 ~]# chkconfig --list|grep mysql
mysqld 0:off 1:off 2:off 3:off 4:off 5:off 6:off←自動起動がoffになっていた
[root@db1 ~]# service mysqld start
Starting mysqld: [ OK ]
[root@db1 ~]# chkconfig mysqld on
[root@db1 ~]# chkconfig --list|grep mysql
mysqld 0:off 1:off 2:on 3:on 4:on 5:on 6:off

以上です。
さらにコストパフォーマンスが向上した、さくらのVPS SSDプランをぜひご検討下さい。

さくらのVPS

北海道出張にて

  • 投稿日:
  • by

先週北海道へ出張していたのですが、週末にプライベートで色々とめぐってみました。
ちなみに、さくらインターネットでは石狩にデータセンターがありますが、札幌から15km程度と意外と近く、周辺のアクティビティが色々とあります。
今回は石狩市内で地元の食べ物を堪能し、隣町の新篠津村でワカサギ釣りをして、登別の温泉に入って帰りました。

まずは石狩市役所前の「升屋」にて地元産の酒肴で舌鼓。
カズノコの磯辺という、珍しいものを頂きました。
カズノコ磯辺


次の日はワカサギ釣りから。
石狩市内でも「茨戸川」という川が凍るので無料でワカサギ釣りを行えるのですが、道具レンタルが無いので新篠津村の「しのつの湯」に隣接したワカサギ釣り場まで行きました。
ワカサギテントワカサギ釣り

残念ながら7人で10匹程度と不漁でしたが、テントのおかげで寒い思いをせずに楽しむことができました。
ワカサギてんぷら

ワカサギ釣りの後はサッポロビール園でジンギスカンを頂きました。
北海道の方には馴染み深いと思いますが、円形のラム肉で野菜をふさいで、蒸すように食べるスタイルがお気に入りです。
サッポロビール園
ジンギスカン

最後に登別で温泉に入って帰りました。

登別駅

北海道というと、冬場は寒いという印象しかない人も多いですが、なかなか色々と楽しめます。
観光にビジネスに、ぜひ北海道をよろしくお願いします。

久しぶりの更新 Part2

  • 投稿日:
  • by

久しぶりのブログです。
最近、ツイッターやFacebookなどで色々と書くものだから、まったく更新ができていませんでした。
というか、更新したときには結構重要なことを書く的な感じになっているので、どうも気楽に更新ができなくて...。

そういえば、2006年4月に「久しぶりの更新」と題して投稿していて、それから7年後に同じようなことになっているのが情けないところです(汗)

ということで、これからは他愛もないことも含めて、ぼちぼちと書いていきたいと思います。

これからもよろしくお願いします。

P.S.
ところで、桜葉愛さんのブログは淡々と更新されています。

創業15周年にあたり

  • 投稿日:
  • by

さくらインターネットは、本日2011年12月23日で15周年を迎えました。
これまで、支えて頂いた多くの皆様に深く深く感謝致します。

舞鶴高専の4年生のときにサーバインフラを貸すための事業を考え、1996年12月23日に sakura.ne.jp というドメインの取得申請をしました。
私自身がサーバの置き場に困っていたことから、それなら自分でやってみようと始めた訳ですが、社会を知らない18歳で起業ということもあり、山あり、谷あり、いろいろなことがありました。
とはいえ、さくらインターネットという名前も、やっている事業もずっと同じであり続けられ、インターネット発展の渦中に身を置けたこと、また微力ながら発展に助力させてもらえたことなど、本当にありがたいことだったと思います。

これからの15年がどのようなものになるのか、おおよそ想像もできませんが、社名にインターネットを冠しているからには、インターネットを発展させていくことこそが会社の使命であるのは変わりません。
30年続く会社は0.02%しかないとのことですが、当社もその仲間として15年後に皆様へ再び挨拶できればと思います。

改めてみなさまありがとうございました。
これからもよろしくお願い致します。

P.S.
今日は母校が主幹校をした第22回高専プログラミングコンテストを観覧すべく、奇しくも創業の地である舞鶴に来ております。
その中で私が起業した時と同じような年代の高専生と時間を過ごし、そしてその人たちの優秀で夢のある姿を見て、あとしばらくは日本も大丈夫だと確信をしました。
この学生の皆さんが社会でもっと活躍できる環境を作ることこそ、先に大人になった私たちの使命だと気を引き締め直したいと思います。

さくらのクラウドと、レッドオーシャン戦略

ブルーオーシャン戦略。
まだ開拓されておらず競争が無い新たなマーケットをブルーオーシャンと呼び、価格をはじめとした血みどろの戦いをしなければならないマーケットをレッドオーシャンと呼びます。
なら、レッドオーシャンを泳ぐより、ブルーオーシャンを泳いだほうが良いじゃないかということ。
これは欧州経営大学院教授のW・チャン・キムとレネ・モボルニュが著したビジネス書で述べられたもので、日本ではランダムハウス講談社から「ブルー・オーシャン戦略 競争のない世界を創造する」として出版されています。
例えば、10分1000円のQBハウスは他の理容店と血みどろの戦いをしているように見えつつ、スピードという差別化要因によって顧客数と業績を伸ばし、実はブルーオーシャンのプレイヤーなのだということが示されています。
これ以上の内容については当該書籍に任せるとして、先日#cloudmixや#yakocloudにて私が発言した「さくらのクラウドにおいて、レッドオーシャンを泳ぎきるというのが戦略」という事について述べてみたいと思います。

さくらのクラウドは、昨年11月に開催されたクラウドエキスポにおいて「何の変哲もないIaaS型クラウドを圧倒的なコストパフォーマンスで提供する」というキャッチで発表をしました。
IaaS型クラウドにおいては、これから競争が激化することが考えられ、各社高付加価値化による差別化を考えている中にあるわけですが、当社はあえて「低付加価値戦略」というのを提起したいと思っています。

アメリカの国立標準技術研究所が発表した「クラウド定義」というものがありますが、それに対する「さくらのクラウド(IaaS)」の解は以下のとおりです。

  • マルチテナント

  • 当社の用意するシステムを共用しコストをシェアして頂くことで、安価かつ大規模、高信頼なシステムを利用頂けます。
  • すばやい増減

  • 数十秒でサーバやストレージを用意したり、解約したりできます。
  • オンラインアクセス

  • 日本一のバックボーン容量の回線を経由し、高速かつクライアントに依存しないアクセスを保証します。
  • 見える化

  • 利用状況を常に把握でき、適切なシステムサイズを判断できます。
  • セルフサービス

  • お客様自身でサーバは当然のこと、ネットワークを含めて自由に設計ができ、全て自動化されています。

私たちの解は、高性能で安定性の高いサーバを安価に提供され、それを自由にネットワーク化でき、使いやすいコンパネ or API で即座に増減できればいいじゃないかというものです。
これはクラウドの定義からまったくぶれていないつもりです。
自動でスケールアップしないし、サーバの中身を管理しないし、メールの大量配信機能も無ければ、CDNも備わっていません。いわば付加価値と呼ばれるものを一切付けず、必要なもの「だけ」を用意したのが「さくらのクラウド(IaaS)」です。
「必要なときに必要なだけ」がクラウドだったはずが、「付加価値」「高機能」というキーワードを元に、必要の無いものに費用を負担させられるのが今のクラウドを取り巻く状況だと思っています。
事業者から見ても、いろいろとライセンス料や運用コストを払って付加価値を用意し、開発コストを払って高機能を付けながら、結局値段競争に入ってコストが回収できないかもというつらいところです。
そもそも付加される価値や機能の多くは事業者間で似通ったことになっており、結局差別化要因にならないということも併せてつらいところです。
むしろ、付加価値を用意せずに、パートナーがAPIを通じて価値・機能を付加して、ともにビジネスが成長する状況にしたいと思っていますし、付加価値向上にヒト・モノ・カネを突っ込むよりは、パートナーに手厚い技術サポートをしたほうが良いと考えています。

こう見ると、私たちのような「高性能、高安定性、低価格」+「拡張性」に徹した日本のIaaSは少なく、タイトルではレッドオーシャンと書きましたが、実際には意外とブルーオーシャンだと考えています。
当たり前のもの(ちゃんとしたもの)を安価に売るというのは、日本のお家芸だと思います。
日本らしいクラウドというのは世界中で売られる車のように、決して品質が悪いわけでもなく、極めてコストパフォーマンスに優れたものにすべきだと思っています。

この戦略は当たり前のように見えますが、みんなやっていないし、少なくとも大規模低コストデータセンター、自社製基盤システム、万単位のサーバの運用ノウハウなど、他社がまねたとしても数年はかかるでしょうし、その間にしっかりとシェアをとり、本当にレッドオーシャンになったときに先行者として強みを持つという形が「本当の戦略」です。
恐らくは、スケールの大きいIaaS事業者と、それを活用する付加価値に強みを持つインテグレーターに二分されるのでしょう。当社としては前者が目標です。

ところで、cloudmixではトイレットペーパーの例を出しました。
「トイレットペーパーを半額にしたからといって、倍の数を買うでしょうか?買わないですよね」という話でした。
もし気合を入れて倍使ったら、お尻が痛くて大変です。
そういった日用品(コモディティ)市場においては、高付加価値化で顧客単価を上げ、トップラインを増やすというのが当然の戦略です。
食料品なども一緒で、とにかくお尻も胃袋も倍の数/量にはなりません。
ましてや、ウォシュレット(シャワートイレ)の登場や、ダイエットの流行など、決して追い風ではありません。

ただ、サーバは安価になればもっと買ってくれるというという世界が待っています。
例えばさくらのVPS 980は、専用サーバ7,800円/月の新規契約を奪いましたが、従来の10倍以上の新規申し込みを受けており、1年で2万を超えるインスタンスが稼働中(解約を差し引いた純稼動数)ですし、上位プラン比率も高まってきました。
コンピューティングリソースが更に安価に、更に使われる世界がくると思っていますので、価格が下がることは市場の縮小を意味するものではないと思うのです。
(といいつつ、月額千円を切るようなIaaSを出すツモリはなく、「絶対価格」を下げることに意味は無いと思いますが...)

elleair.jpg
ところで、私の嫁がタイムリーに「トイレットペーパー買いすぎたー!」と言ってきました。
Amazonの定期便で見積もりを誤ったようで、まだ在庫があるのに送ってきたという話です。
そこで「いっぱいつかわな無くならへん。」と一言。「いや違うやろ」と突っ込み。場所以外困ること無いから、無理して使わなくていいだろうと。
しかしまあ、自宅のトイレットペーパー在庫を増やさせる or 定期的に送りつける戦略は、日用品における良い回答かもと思った瞬間でした。
クラウドではなく、我が家の日用品から攻めてくるとは、恐るべきAmazonさん。機関の陰謀ですね。

と、オチがついたところで。

ちなみに、IaaSだけでなくPaaSやSaaSに対する戦略もありますが、それは機会が来たときにということで。個人的にはPaaSがさくららしさを表現できるステージだと思っています。

satoru.net様からの質問と回答について

  • 投稿日:
  • by

さくらインターネット、HDD故障時に有償請求という記事において、satoru.net様より私の見解を求むと連絡頂きましたので、このエントリーを書かせて頂きます。
詳しくは上記のリンクからご覧頂くとして、経緯だけまとめてみます。

1. お客様の専用サーバのHDDにおいてIO Errorが発生したため、当社へ連絡を頂く
2. 当社側で、すぐにハードウェア交換をご提案する(無償対応)
3. HDD以外のハードウェア交換をしたものの、HDDが認識しなかったため、HDDの交換とOS再インストールをご提案する(無償対応)。
4. その上で、壊れたHDDを接続することもご提案する(5,250円の有償対応)。
5. 壊れたHDDの接続を無償で出来ないのかという連絡を頂く
6. データについては保証しかねるので、(サルベージ等に係る作業については)有償で対応させて頂きたいとご連絡。

この対応について、前述のブログ記事とともに、私のツイッターアカウントへmention頂いたというものです。

この件について、satoru.net様と各種ソーシャルメディアで述べられていることに対する、私≒さくらインターネットの見解は以下の通りです。

  • 当然のことながら「不良HDDを提供した」というつもりはない。(HDDが結果として故障することは一般に知られており、エイジングは行っているものの、絶対に故障させない保証は非常に困難です。)
  • バックアップサービスやRAIDなども用意しており、(お願いベースですが)バックアップは行って頂きたい。
  • データセンターのサーバでは、通常のパソコンのようにホイっとセカンダリを接続できるものでもない(専用サーバラック内ではセカンダリHDD用の場所が確保できず、旧HDD接続サービス用のサーバを用意しています)。
  • 旧HDD接続サービスは約款に記載したうえ、ウェブ上において金額、フローとも紹介している。
    案内: http://www.sakura.ad.jp/function/maintenance/hdd-attach.html
    約款: http://www.sakura.ad.jp/agreement/[a]yakkan3_dedicated.pdf
  • ただし、HDD接続は当社側でしかできない作業であり、無償で行ったほうがよいと思う。

私としても、ハードウェアの無償交換等は当然と考え行っておりますが、データの復旧にかかわる部分についてはバックアップやRAID、冗長化などを行って頂いているお客様がおられる以上、そのコストを基本価格に転嫁したくないというのが本音です。
しかし同時に、現地でしかできない作業については、出来るだけ無償化したいという想いもあります。
このような中、今回の件については、当社が行わなければお客様側でどうしようもないというものであり、リブートなどと同様に無償化するべきだと考えました。

ということで、satoru.net様のブログ記事で提案頂いた形で、旧HDD接続サービスについては、これまでは有料だったものを、明日から無料(一週間)へと変更することとしました。
急遽決めたことなので、約款やウェブサイト等の修正はこれから行います。
satoru.net様についても、返金 or 充当等の対応をさせて頂きます。

最後に言い訳がましいのですがやはり述べておきたいのは、今回の対応についてはHDD故障の責が当社にあるという認識ではなく、あくまでも現地でしか出来ない作業をなるべく無償にして、お客様の金銭的なご負担を少なくしたいという想いからです。
さらっと「無償にしました!」とだけ書いてもよかったのですが、私の見解、想い、背景、判断基準などを知ってもらいたいと思って、長々と書かせて頂きました。

なお、ご意見頂きました satoru.net様には、ご利用頂いていることに対する感謝はもちろんのこと、貴重なご意見を頂きました事に大変感謝しております。
今後とも、様々な事柄について改善に努めたいと思いますので、さくらインターネットをよろしくお願い致します。

ウェブ開発者のための、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 最新版に対応すべく修正しました。

大災害時におけるアクセス負荷を軽減させるキャッシュサーバ提供について

  • 投稿日:
  • by

先日発生した東北地方太平洋沖地震に際し、公的機関等のウェブサイトへのアクセスが集中し、サーバへの接続に支障が出ることが増えています。
そういった事態を解消すべく、ICT関連各社により負荷低減のための無償支援を致しております。

※50音順
※問い合わせ先は以下に記しています。

今回はその一例として、キャッシュサーバやミラーサーバを使った負荷低減方法を紹介いたします。
なお、この方法はサイト管理者の方の協力があれば非常に効果が高いものですので、接続の良くないサーバなどがありましたら、管理者の方に本ページを紹介頂ければ幸いです。

まず、アクセスが増えて接続できない状態を解説します。
以下の図のように、利用者からのアクセスが増えて、ウェブサーバや回線が圧迫されるために、アクセスが出来なくなります。

キャッシュサーバを使わない場合

それに対して、キャッシュサーバという専用のサーバを中継させることにより、負荷を軽減させるというのが今回の方式です。
以下の図のように、利用者からのアクセスをキャッシュサーバで受け付け、そのアクセスを取りまとめてウェブサーバに接続します。

キャッシュサーバを使う場合

利用するに当たっては、上記の事業者側でキャッシュサーバに登録を行い、サイト管理者様はドメイン名に割り当てられたIPアドレスをウェブサーバからキャッシュサーバへ変更するだけです。

以下のように、既存のウェブサーバをミラーする方法も提供可能です。

ミラーサーバを使う場合

担当の技術者の方へ

ご利用頂くには、ゾーン情報の変更をおすすめしています。
キャッシュサーバ、ミラーサーバのみを開設することも可能ですが、大元のウェブサーバのトラフィックが減らせない限り、有効性が低減されてしまいます。
Aレコード、もしくはCNAMEレコードを編集頂ければ幸いです。

お問い合わせ先は以下のとおりです。

※メールアドレスについては、at の部分を@に置き換えてください。

現状を少しでも解消するため、全面的な協力をさせて頂きますので、担当者の方にお知らせ頂ければ幸いです。

東北地方太平洋沖地震に対するサーバインフラ支援について

  • 投稿日:
  • by

先日、東北地方において、大地震が発生致しました。
被災された方には、心よりお見舞い申し上げます。

この事態にあたり、インターネットサイトの多くがダウンしたり、繋がりにくい状態になっており、さくらインターネットにおいてもそのようなサイトをお手伝いすべく、大きな帯域の提供や、ミラーサーバ運用などを行っております。
既に、3月12日に私のTwitterを通じて公表しており、たくさんのサイトをお預かり致しておりますが、Twitterのみの情報となっておりましたので、改めて以下に掲載させていただきます。

  • サーバがなくて困っている方へ

  • さくらのVPSであれば、申し込み後、直ぐに無料で利用が開始できます。(だいたい30分くらい)
    ただし、無料期間中は2Mbpsの帯域制限がありますので、カスタマーサポート宛、もしくは私のTwitter @kunihirotanakaを通じて制限解除の依頼をいただければ、無料期間中でも帯域制限を解除致します。

    http://vps.sakura.ad.jp

    申し込みの際には、「振込み」を選んで頂ければ、料金がかかることはありません。
    ※クレジットカードを選択すると、2週間後に課金が開始されてしまいます。

    あと、1.5G 4G 8G の3プランは在庫が逼迫し始めていますので、512MBもしくは1GBのプランを選択頂ければ幸いです。

  • とりあえずホームページを立ち上げたい方

  • さくらのレンタルサーバについても、無料で利用が開始できます。(同じく30分くらい)
    この際に、アクセスが増えすぎると503エラーが出てしまいます。
    ついては、上記のVPSと同様に、問い合わせをいただければ制限を緩和致します。

    なお、申し込まれる際には、比較的アクセス耐性が強いプレミアムプランをおすすめします。

    http://www.sakura.ne.jp

  • ミラーサイトを作りたい方

  • ※これは、さくらインターネットで公式にサポートしているものではありません。

    https://tanaka.sakura.ad.jp/mirror/において、ウェブサイトのミラーを行っています。
    災害関係のサイトを運営されている方で、アクセスに問題がある場合には、上記のミラーシステムをご活用頂くことで、少しでもサーバ負荷を抑えられます。

なお、現在新規に受付しているサーバは全て大阪にあります。
よって、停電の影響はありません。
東京電力管内のサーバを一つでも減らせるよう、協力頂ければ幸いです。

現在、既に多くのサイトにご協力させて頂いておりますが、まだまだアクセスの出来ないサイトも多くございます。
ついては、この情報を広く伝えていただき、ひとつでもアクセスに問題がなくなれば幸いです。

現在、他の団体にも広がっています。
ぜひ、多くの皆さんにお伝え頂ければ幸いです。

さくらの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ライフをお送り下さい。