データホテル

第4回NHNテクノロジーカンファレンスのお知らせ

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - 第4回NHNテクノロジーカンファレンスのお知らせ
このエントリーをはてなブックマークに追加
株式会社データホテルの伊勢幸一です。
エンジニアの皆様、ご無沙汰しております。おまたせいたしました。
来る2013年3月10日(日曜日)、第4回NHNテクノロジーカンファレンスを開催します!
今回のテーマはこちら!
「ザ ・ データセンター」
〜アプリは会議室で動いてるんじゃない!データセンターで動いてるんだ!〜」

(ベタなコピーですいません・・・)

普段、ターミナルエミュレーターを介してしか触れることの無いサーバ達ですが、ほとんどのサーバはデータセンターと呼ばれる倉庫みたいな殺風景なお部屋でシュンシュンと鳴きながら皆さんのアプリケーションを稼動させています。そのデータセンターの中では一体何が起きているのか?データセンターエンジニアは中で一体何をしているのか?データセンターの未来は?とか。そこで、データセンター生活の一幕を皆さんで共有してみようということで計画しました。

対象者 
・ SNS、E-Commerce、ソーシャルメディア系のプログラマ及びエンジニア
・ データセンター、ホスティングサービス利用者
・ データセンター、ホスティングサービス提供者

予定されている講演は以下の通りです!

講演概要

講演1
14:40-15:10
「Open Compute Project Japan設立の背景と経緯」
鵜澤幹夫氏 (Mikio Uzawa)氏
Agile Cat 、OCP Japan 副座長


概要:
Facebookが提唱したOCPは、スケーラブルなコンピューティングにとって、もっとも効率の良いサーバ/ストレージ/データセンターなどのハードウェアを設計し、提供していくためのエンジニア・コミュニティ。OCPJはこのOCPの活動に賛同し、日本市場に向けてOCPの存在と意義を広報するとともに、日本からの提言も行うため2013年1月に設立されました。その背景と経緯をOCPJの発起人であり副座長の鵜澤氏からお話頂きます。

講演2
15:15- 15:45
「データセンターの不思議運用テクニック」
〜 機械にやさしい高密度実装TIPS 〜

菊池之裕氏 ブロケード コミュニケーションズ システムズ株式会社
芦田宏之氏 シスコシステムズ合同会社

概要:
如何にブレーカーをすっ飛ばさずに、サーバ達を燃やさずに一つのラックにどれだけのサーバ、コンピューティングリソースを詰め込む事ができるか?データセンターの中では一般の人には思いも拠らないエンジニア達の黒魔術で運用されています。そんな不思議テクニックをここでコッソリとお話ししていただきます。

講演3
15:50-16:20
「こんなデータセンターはいやだ!」

岩崎磨氏 楽天株式会社

概要:
障害対応で駆けつけたのに前日事前登録が無いとデータセンターに入館できない? 年次点検のため明日は停電?全サーバに電源入れるとブレーカーが落ちる? 最寄り駅から歩いて40分、シャトルバスは1時間当たり2本?半径2km以内にあるのはジュースの自動販売機のみ。こんなデータセンターあったらいやだという経験に基づいたお話をしていただきます。
講演4
16:40-17:10
「こんなデータセンターユーザはいやだ 」
〜 巡回者はミタ 〜


芦田宏之氏 シスコシステムズ合同会社
菊池之裕氏 ブロケード コミュニケーションズ システムズ株式会社

概要:
マシンルーム内は飲食厳禁なのにカップ麺の匂いが充満している。ルータ1台納品するのになぜか立会い15人、作業者1人。床が水浸し。ラックの中から物凄い轟音が聞こえる。データセンターの中ではその利用者が色々な事をしているようです。データセンター巡回者の見た不思議なユーザ、痛いユーザの実例を紹介していただきます。
講演5
17:15-17:45
「日本のホスティング事業は何処へ向かうのか?」
〜 技術出身経営者によるパネルディスカッション 〜

モデレータ 伊勢幸一 株式会社データホテル
パネラー
田中邦裕氏 さくらインターネット株式会社 代表取締役社長
嶋田健作氏 株式会社データホテル 代表取締役社長


概要:
データセンター市場は年々拡大すると予測されているけど、それ以上に競合他社が乱立しまくり。クラウドのおかげでホスティング代は軒並み大暴落。建築資材、電気代、サーバ機器代はみな同じで、差別化できるのは土地の値段だけ? 高付加価値と言っても考える事は皆同じ。今後ホスティング事業者が生き残るための次の一手は何だ?人か、物か、金か、それとも技術か?この厳しい市場状況をどう打破していくのかを技術系社長のお二人に議論していただきます。


開催概要はこんな感じです。

日付2013年3月10日 日曜日 (土曜日じゃないからねー)
時間14:00開場 14:30開始 18:00終了及び撤収
場所渋谷ヒカリエ 27F NHNジャパン Cafe
懇親会有ると思います

後日、タイムチャート、カンファレンス会場、懇親会会場案内等の詳細をお知らせすると同時に参加募集を開始します。ぜひぜひ @ld_tech@941@ibucho あたりをチェックしていただければ幸いです。

ハッシュタグは #nhntech です。

--- 2013.2.13 追記 --- 参加募集ページは 【こちら】 です。

EX-CLOUDの仮想化運用術

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - EX-CLOUDの仮想化運用術
このエントリーをはてなブックマークに追加
データホテル 田畑です。

データホテルで展開しているEX-CLOUDの仮想化には、Parallels Virtuozzo Containers(OpenVZの商用版)を使用しています。 Virtuozzoには特徴的な機能が色々ありますので、今日はその中から2点取り上げてみたいと思います。


■ストレージ不要のライブマイグレーション


他の仮想化技術では、二次記憶装置に外部ストレージを使用して、サーバに演算と一次記憶のみを任せることで、 ライブマイグレーションを実現させていますが、Virtuozzoではマイグレーション時にデータなどを移行先に同期させることで、 ストレージ不要のライブマイグレーション実現させています。 この機能は最初かなりビビッて使っていましたが、乗りこなしてしまえば実用に耐えますので、紹介したいと思います。

マイグレーションはおおまかに、以下のような流れで実行されます。
---------------------------------
1.移行先へデータ、プロセスの移行
2.メモリ内容の移行
3.IP付け替え
---------------------------------
マイグレーションはVirtuozzoカーネルが提供しているチェックポイント機能で実現されています。 マイグレーション時のプロセスを見ると、データ自体のやり取りはrsyncが使われています。

移行時は以下内容も保持されるので、無停止での移行と言って良いと思います。
---------------------------
起動プロセスとステータス
オープンファイル
ネットワークソケットと接続
---------------------------
IP付け替えの時にパケットが少し落ちますが、許容範囲内です。

注意点として、移行対象のVPSが作成されたテンプレートと全く同じテンプレートを移行先に用意しなければなりません。 これはOSテンプレートからキャッシュしたOSイメージを読み込んで、VPSを起動しているためです。

▽OSテンプレートとOSイメージについて


EX-CLOUDではEZテンプレートというテンプレートを使用しています。 EZテンプレートにはrpmなどのファイルは含まれておらず、リポジトリ、インストールパッケージ名などが書かれたテキストで構成されています。 このテキスト情報を元に、OSイメージ作成しています。

▽OSテンプレートcentos-5-x86_64の構成


Virtuozzoはディレクトリパスで、OSテンプレートを判別しています。
/vz/template/[OS名]/[バージョン]/[アーキテクチャ]/config/os/default/

centos-5-x86_64の場合以下のようなパスになります。
/vz/template/centos/5/x86_64/config/os/default/

このディレクトリ以下にテンプレート構成ファイルが配置されていて、 代表的なファイルは以下の2ファイルです。

packages:インストールするパッケージが記述されています。
------------------
authconfig
bash
crontabs
diffutils
rootfiles
info
・・・
・・・
・・・
------------------
repositories:レポジトリのリストが記述されています。
------------------
http://mirror.centos.org/centos/5/os/x86_64
http://mirror.centos.org/centos/5/updates/x86_64
------------------
以下を実行してテンプレートをキャッシュします。
# vzpkg create cache
すると、repositoriesからpackagesに記述されているパッケージが取得され、 OSイメージとしてtarボールに固められます。
/vz/template/cache/centos-5-x86_64.tar.gz
このOSイメージを元にVPSが作成されます。 実際に作成する場合はこんな感じです。
# vzctl create [VEID] --ostemplate centos-5-x86_64
ここでキャッシュしたOSイメージを消すとどうなるか? VPS内部では、OSイメージをリンクのような形で読み込んでいますので、 全構成ファイルがリンク切れファイルのような動きをします。 rm -rf / と同じ効果です。

■無停止でのリソース値変更


VirtuozzoはOS仮想化ですので、当然と言えばそれまでなのですが、 無停止でリソース値変更が可能です。 EX-CLOUDでは主に以下設定をプラン別に用意して、プラン変更があった場合は 無停止で割り当てリソースを上下させています。
---------------------------
CPU 使用量の制限値(cpulimit)
コンテナが消費するディスク容量の総サイズ(diskspace)
ディスク iノード数(diskinodes)
メモリの制限値(slmmemorylimit)
---------------------------
最近ではハイパーバイザ型もホットアド機能が実装されているので、 この優位性は無くなりつつありますが、気軽に設定変更出来る点では まだOS仮想化に分があるように思います。

▽CPU

Virtuozzoのcpulimitは%単位で設定を行います。 CPUコア数×100%が全体の処理能力になりますので、QuadCore+HTのサーバだと 8*100=800%が全体の処理能力です。

CPU使用量の制限値されたVPS内部では/proc/cpuinfoのcpu MHzが変化します。
制限なし
cpu MHz         : 1862.037

25%制限
cpu MHz         : 352.768
VirtuozzoがMHz単位でCPUリソースを割り振ってるわけでは無いのですが、 表現としてはわかりやすくて良いと思います。

▽ディスク

ディスクを100GB使っているVPSのディスク容量を50GBに縮小するとどうなるか?
Size:50GB、Used:50GB、Avail:0GB
もちろんディスクフルになりますが、100GBのデータにはフルアクセス出来ます。 50GB以下にディスクを減らすと50GBでキャップされます。 良く出来てます。

▽メモリ

メモリを2GB使っているのVPSのメモリ容量を1GBに縮小するとどうなるのか?
OOM Killerにプロセスがバッサリkillされます。 こっちは容赦無いです。


このような機能を使いながらEX-CLOUDの運用をしているのですが、 そのEX-CLOUDから低価格VPSプランEX-LITE(エクスライト)を先日リリースしました。

http://ex-cloud.jp/ex-lite/

EX-LITE(エクスライト)の特徴

・1U(SASディスク 30GB、メモリ1GB)あたり月額1,050円
・1U〜5Uまで無停止スケールアップ可能
・WebDAV設定済みですぐ使える
・LANも使える(別料金)

低価格VPSのこのプラン、初期無料&最低利用期間が1ヶ月となっています。 サーバーエンジニアの方々による検証環境や開発環境としての活用事例が増えてきていますので、 皆さんも機会があれば是非ご検討いただければと思います。

運用から生まれるスクリプト

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - 運用から生まれるスクリプト
このエントリーをはてなブックマークに追加
こんにちは、ネットワーク事業部オペレーショングループの後藤です。

データホテルのサービスを担っているオペレーショングループでは、サーバセットアップ時にセットアップの効率化と正確性を図るため、予め先代たちが築きあげてきたセットアップ用のスクリプトを使用しセットアップ作業を行うことが多々あります。

セットアップとは、OSのインストールからミドルウェアの構築まで、顧客のご要望に沿った形でサーバを造りあげて引き渡すまでのことを意味し、各々顧客に合わせたセットアップ方法にて作業を行っております。その一連の流れの中から、OSインストール後のできたてホヤホヤのサーバに対して行っている、あることを取り上げてみたいと思います。


◇日次バックアップ


データホテルではレンタルサーバとして提供しているサーバに必ずディスクが2本以上装填されております。これはデータホテルのバックアップ方法の一つとして、日次で同一サーバ内でディスク毎にバックアップを取るためです。

例えばディスクが2本装填されている場合、指定の時間になったら、セカンダリディスクをマウントしプライマリディスクからセカンダリディスクへまるごとコピーするというスクリプトが走る仕組みになっていたりします。※場合によってはコピー対象外にするディレクトリなどもあります。

◇魔法スクリプト


上記のような理由からサーバは常にセカンダリディスクをマウントできる環境にある必要があります。
ところが、OSインストールの際にセカンダリディスクの構築を行わずにとりあえずプライマリディスクのみにパーティションを切り、ファイルシステムを作成してセットアップすることが往々にしてあります。
そんな時、できたてホヤホヤサーバにはセカンダリディスクへの構築が行われていないためセカンダリディスクをマウントしようとすると「マウントできないよー」と怒られてしまいます...

そこで先代たちが数々の経験をもとに作ってくれた魔法のスクリプトが登場します。
魔法スクリプトは、そんなできたてホヤホヤサーバに対してセカンダリディスクをマウントしてくれるよう環境を整えてくれる役目を果たします。

具体的にLinuxの場合、
- プライマリディスクと同じようにセカンダリディスクのパーティションを切る
- セカンダリディスクのファイルシステムを構築
- プライマリディスクと同じようにセカンダリディスクのswapを作成
- セカンダリディスクをマウントしgrubをインストール

こんなことをしてくれます。うーん、スクリプトひとつでここまでしてくれるなんてありがたい。


◇ファイルシステムの構築


次にスクリプトの中で行われているファイルシステムの構築という工程に焦点を当ててみます。

セカンダリディスクへプライマリディスクと同じ様にパーティションを切ったあと、セカンダリディスクへファイルシステムを構築するのですが、ファイルシステムの作成には色んな方法があります。

データホテルでは下記のコマンドとオプションにて作成しております。
mke2fs -j -i 4096 セカンダリディスクのマウント領域


言わずと知れた、それぞれこんな意味になります。
mke2fs : ファイルシステムを作成するコマンド
-j : ext3ジャーナルを持ったファイルシステムを作成
-i : 何バイト毎に inode を1つ作るか(inode-ratio)を指定※

※ここでは 4096byte 毎に inodeが1つ作られるという意味。


◇ファイルシステムとブロックサイズ


ここでlinuxのファイルシステムについておさらいしてみましょう。ハードディスクは「セクタ」という単位でフォーマットされており、そのいくつかまとめたものを「ブロック」といい、ファイルシステム上ではこのブロックがデータを保存する最小単位となります。
現在よく使用されているlinuxのファイルシステム「ext3」では、デフォルトのブロックサイズが4096byteであり、mke2fsコマンドで任意のブロックサイズに指定することも可能ですが、linuxカーネルのページサイズと同じデフォルトサイズの4096byteを用いることが多いようです。

4096byteブロックがデータ最小単位なので、例えば1k byteのファイルを作成した場合も4096byte分使用されることとなり、4096byte-1024byte=3072byte 分が無駄になってしまいます。しかし実際にはファイルシステム内で4Kbyte未満のファイルが占める割合は、メール専用サーバやNetNewsサーバを除けばそれほど多くはありません。特にデータホテルの顧客システムはWebをベースとしたシステムが多く、小さいサイズのテキストデータなどはSQLサーバに格納され、ファイルシステム上に4Kbyte未満のファイルが直に置かれることは稀です。

◇inode-ratioサイズ


では、前に戻って先のスクリプトの中でファイルシステムを作成する際、inode数を指定する意味を考えてみます。

この場合ブロックサイズがデフォルトの4096byteで作られていますが、仮にinode-ratioの指定(-i のオプションの値)を1024byteにしたらどうなるでしょうか。データ最小単位であるブロックの値が4096byteということは、1ブロックあたり4つのinodeが準備される事を意味しますが、全てのデータが1ブロックに収まったとしてもinodeの4分の3が使用されずに残り、無駄なディスク領域をinodeに割り当てることになります。

また、-i オプションの値を極端に大きくした場合、inodeによるディスクのオーバヘッドは減りますが、逆にinodeが枯渇する恐れが生まれます。

つまり
inode-ratio値<ブロックサイズ値 ---> ディスクの無駄
inode-ratio値>ブロックの値 ---> inode枯渇の恐れ
ということです。

それではブロックサイズに対するinode-ratio値の最適値は幾つなのでしょうか? /etc/mke2fs.conf ファイルにこれらの値のデフォルト値が以下のように指定されています。
[defaults]
base_features = sparse_super,filetype,resize_inode,dir_index
blocksize = 4096
inode_ratio = 8192

しかし、ここで問題が発生します。mke2fsコマンドに-iオプションでinode-ratioを指定せずにセカンダリディスクのファイルシステムを作成したところ、バックアップに失敗しました。プライマリディスクのデータがセカンダリディスクに入りきらなかったのです。プライマリディスクとセカンダリディスクのinode数にずれがあり、ディスクの総容量ではなくセカンダリディスクのinode数が不足していたためです。

原因調べてみたところプライマリディスクのinode-ratioがデフォルトではない4096で構築されていました。さらに調べてみたところlinux付属の純正インストーラはシステムディスクインストール中、わざわざデフォルトではないinode-ratio 4096でファイルシステムを作成していたのです。そこでデータホテルではインストーラに手を加えるのではなくセカンダリ側のinode-ratioを4096で統一してセットアップすることとしました。インストーラに手を加えるとOSがアップデートされるたびにインストーラを改修しインストールディスクを作成しなければならないので、ミスが発生しやすいという事のようです。

今回、記憶媒体であるディスクデータの基本的な部分に触れてみただけですが、ファイルシステム作成だけでも意外と奥が深かったり、運用経験上、理由があってオプション値が決められたりしているものだということがわかりました。

例に上げたスクリプト以外にも作業効率、正確性を図るための様々な工夫と努力がされた先代たちが築き上げたスクリプトやインストーラーなどが存在します。データホテルには多岐にわたるエンジニア、スペシャリストがいて、日々サービス向上のために邁進しているのです。その人たちに近づくように、また、より一層お客様に喜ばれるサービスを提供するために今日もまた真っ黒い画面とにらめっこです。

データホテルで見かけるソフトウェアとハードウェア

カテゴリ
ブックマーク数
このエントリーを含むはてなブックマーク はてなブックマーク - データホテルで見かけるソフトウェアとハードウェア
このエントリーをはてなブックマークに追加
おばんです。(※注)オペレーショングループのITOHです。
(監修者※注: ITOHは22:00-7:00勤務の第三シフトなので、挨拶が『おばんです』になるそうです)

入社して短いこともあり、業務内容メインではなく、データホテルで見かけたソフトウェアやハードウェアについて、自宅で触っていた事によって役立ったりしたことなどを交えて書いてみたいと思います。

まずはソフトウェア周りから。

■仮想化関連


XenとVMwareについて。最近はkvmが気になっています。

▼Xen
入社してほどなく、CentOS上でXenをいじっていました。今年の初売りで低消費電力なPhenom II X4 905eを購入し、CPUを載せ換えたのを良いことに自宅でXenをつかったサーバを24時間稼動させ始めました。準仮想化での導入、ゲストを複数稼動、ゲストのCPU・メモリの設定方法から定期的な更新とファイルのバックアップ環境の構築。色々いじっていればゲストを操作するコマンドも覚えるもんです。自社サービスではXenサーバがそれなりに稼動し始めているのですが、ゲストで障害が発生した場合の対応速度がかなり速くなりました。

Xenの良い点は準仮想化でもドライバ周りで困ることがほとんどないことでしょうか。結構適当なNICでも認識してくれるのが良いです。
自宅で勉強する環境を作る、という意味では下記のVMware ESXiよりも個人的には良いと思います。

また、ゲストOSの複製が簡単です。イメージファイルのコピーとXenの設定ファイルの編集(UUIDとか)。その後コピーしたゲストを起動(またはイメージマウント)し、ホスト名・IPアドレス・MACアドレスを編集すればOKと。そのため、ベースとなるイメージを作成しておくことで、新しくゲストの環境が欲しくなった場合に短時間で用意することができます。

▼VMware ESXi
無料版も出たESXi。使用されているお客様もちらほらと見かけるようになってきています。先日、無料版を導入してみました。Xenと異なり管理用に別途Windowsマシンが必要になる点が面倒。また、ドライバがシビア。現在24時間稼動していると書いたマシンのXen環境では問題く認識したオンボードのNICが認識しなくて、最初はインストールの時点でこけていました。仕方がないので比較的安いIntelのPWLA8391GTデスクトップアダプタ@約4000円を購入してインストール。導入したバージョンは4.0でした。

インストール後、vSphere Clientを使ってゲストを導入。この際はCentOS5.4とWindowsVista 32bitを試しにインストール。vSphere Clientからコンソール操作ができるんですけど、正直遅いです。VMware Toolsを入れても遅い。sshやリモートデスクトップを使ったほうが快適でした。(vSphereClientを動かしていたマシンのCPUはCore i7 920)

お客様から預かっているサーバはLinux系が大半を占めています。VMwareESXi上でLinuxが稼動していようと、sshで接続が可能なトラブルであれば比較的対応はスムーズです。ESXiを使用しているお客様はまだ少ないため、ssh接続できないようなトラブルが発生するとなかなか焦ります。そもそもトラブルの数も少ないため、経験値が少ない点も焦る理由かと思います。

多少とはいえ自宅で触った経験があるだけでだいぶ焦らないで対応できますし、構成の把握も速くなります。とはいえ、個人的に自宅での学習用には敷居(ドライバとか管理環境とか)が高くて勧められない印象でした。ESXiではなくVMware PlayerやVMware Serverを使う方が学習用環境を作るという意味では楽だと思います。

■Linux


各種ディストリビューションについて

▼CentOS
今現在データホテルで一番稼動しているディストリビューション。Redhatクローンで枯れている事もあり、安定しています。自宅である程度触っているだけでも仕事に役立つことはたくさんあると思います。OS導入、iptables、TCPwrapper、logrotated、chkconfig、yumにrpmといった基本部分は最低限押さえておきたい要素かと思います。前職ではRedhatばかりだったこともあり、自宅でCentOSを使うのは避けていました。いや、なんか仕事しているような気分になって、ねぇ…

先に書いたように自宅で24時間稼動させているOSとして使っています。ゲスト複数で結構妙な構成で使っていますが、今のところ安定して動作しています。

▼Debian GNU Linux
データホテルでもDebianが導入されているお客様がいます。CentOSは所謂Redhat系と異なり、パッケージ管理がaptとなっていたり、Redhat系と異なる部分も多く、Redhat系しか触ったことがないとシステム管理関連で戸惑います。自宅で64bitのLinuxを試してみよう、といった感じで初めてDebianを触ったときはネットワークの設定でまず戸惑い、aptで戸惑いと数日かかって環境整えていた覚えがあります。

余談ですが、Firefoxの名前が異なるのも最初は「?」でした。Redhat系を触った事がある方はDebianでも同じような設定ができるようになってると色々と楽かと思います。

▼Ubuntu Linux
非常にお手軽なDebian系のディストリビューション。データホテルでは見た覚えがないです。とはいえ、とっつきやすいディストリビューションなので、いきなりDebianよりはUbuntuで多少慣れてからもでも良いかと思います。ドライバが豊富でデバイスの認識率が高いので、余っているパソコンがあってLinuxの勉強に使いたい場合は良い選択肢だと思います。利用者が増加していることもあり、情報が多い点も良いです。

しかし、簡単にマルチメディア系の再生とかができてしまうので、誘惑に負ける場合は止めた方が良いかもしれません(笑)。X-Window無しで構築すれば良いかもしれませんが、Linuxに不慣れな人にはお勧め出来ないかと思います。古いマシンでもインターネットの閲覧、メールや文書ファイルの編集程度であれば十分動いてくれると思います。

▼Gentoo Linux
こちらもデータホテルでは見た事ないですが、書きたいので書きます(笑)。おそらく書いている中では導入の難易度が一番高いディストリビューション。最近はGUIのインストーラーがあるそうなのでそうでもないかもしれませんが、Gentooを使うのであれば全てCUIで導入してもらいたい。カーネルのビルドから自分で行う必要があり、導入するマシンのCPU、チップセットやNICのメーカーといったハードウェアの知識も必要になります(必須ではないが合った方が良い)。

あまり最適化しないのであればそうでもないかもしれませんが、それではGentooを選ぶ意味が薄れると思います。GentooはPortageというパッケージ管理を採用しており、emergeコマンドを使い、基本的にソースコードからコンパイルして各種ソフトウェアを導入することになります。そのため、バイナリで配布しているディストリビューションと比較し、マシンスペックが低い場合は導入に時間がかかってしまいます。バイナリパッケージもあったかと思いますが、Gentoo使うのにバイナリパッケージを使うのはナンセンスでしょう。先に書いたとおりカーネルのビルドから行うため、ある程度Linuxに触れた人がGentooのインストールを行うと、少し深堀した部分の知識が増えて良いと思います。

昔はXのコンパイルに1日かかることがザラで、コンパイルエラーなんて出ようもんなら本気で凹んでいました。昨今のCPUであればそこまで時間が掛かる事はまずないので、空いているマシンがあるなら導入してみると面白いと思います。

■ミドルウェア関連
データホテルでよく登場するミドルウェアを挙げるとこんな感じです。
  • Apache、Tomcat

  • MySQL、PostgreSQL

  • Qmail、Postfix

  • Cacti、MRTG、Awstats


  • 私自身は前職ではメール系の構築が多く、MySQLとPostfixをよく使っていました。Apacheはたまに簡単な設定をする程度で初心者程度の知識しかありませんでした。そのためMySQLは大きな苦労は無かったのですがApacheのVirtualHostやSSL設定などはほぼ未経験に近かったので時間を見つけては試しに設定をいじっていました。

    QmailはPostfixの経験があったおかげで設定ファイルの対応がわかってくると、基本的な部分はだいたい理解できましたけど、まだまだ識も経験も不足していると感じています。Cactiなんかは全く経験がなかったのでとりあえず導入して、分からないなりに色々設定をして覚えていっている最中です。

    データホテルではこの他にも色々なオープンソースソフトウェアの導入・設定を行うことが多々あるため、マイナーな物でも経験があると思わぬところで役に立ったりします。

    データホテルでよく使われるソフトウェアはRPMパッケージ化されているものが多いです。とはいえ、お客様の要望やサーバ構成の都合によりソースからインストールすることもままあります。

    ソフトウェア関連はこの辺にしてハードウェア関連でも。

    ■CPU


    データホテルでは基本的にIntelのCPUを使ったものが多いです。ちょっと前のものだとPentium4だったり、最近だとXeonの5400番台でしょうか。Xeonの5500番台は見た覚えがない。Nehalemコアではメモリコントローラが内蔵されたので良いと思うんですけど。と、思っていたのですが、最近発注してるものは5500番台のもあることを確認しました。AMDの物は最近までありませんでした。自社サービスのサーバがソケットAM3なCPUの物も使われ始めています。

    Intelより先にメモリコントローラを内蔵し、また64bit拡張もIntelより先と個人的にはAMDは好きです。しかし、最近の元気の無さが心配です。CPUの場合、64bit拡張が付いているもの、仮想化支援が付いているもの、ぐらいの区別は付くと良いかなぁと思います。

    IntelとAMD、両方からもうすぐ6コアが出てきます。組み込み向けだとIntelは既に売り出されていますが。また、ハイエンドでは既にありますが、個人的には次が本命だと思っているので非常に楽しみです。6コアとメモリ12GB、SSDにしたら相当サーバ集約できんじゃね?、と妄想中です。

    余談ですがどちらかのCPUしか使わない、というのも見かけますが、個人的にはそのサービスやコストに見合った物をその都度選べば良いと思っています。

    ■メモリ


    先のCPUで書いたとおり、結構前のもありますのでDDR、DDR2、DDR3と。registered, ECCとか。メモリはそこまで知らなくても困らないかもです。時期的にRDRAMのもあるのかな?

    ■HDD&SSD


    接続の規格でPATA、SATA、SAS。RAIDレベルについては知ってると良いでしょうか。パラレルなSCSIは見た覚えが無い・・・。どこかにはあると思いますが。データホテルではRAIDの使用頻度は低い印象です。ローカルバックアップと呼ばれているバックアップを行う事もRAIDの使用頻度が低い理由かと思います。

    また最近ではSSDといったHDDより容量あたりの単価は高いけど高速な物も徐々に使われてきています。

    今のところデータホテルでは使われていないはずですが、Western DigitalのWD Caviar Greenシリーズの64MBキャッシュのものがbigsectorになりました。Linux(WindowsXP)では何も意識せずにフォーマットして使用すると性能が落ちるので、今後購入されたらセットアップの手間が増えるなぁ、とか思ってたりします。
    Linuxのbigsector正式対応っていつなんでしょうね。

    今のところ発注しているWesterDigitalのHDDは32MBキャッシュの物のみだな、とチェックしてたりします:-p

    データバックアップ再考

    カテゴリ
    ブックマーク数
    このエントリーを含むはてなブックマーク はてなブックマーク - データバックアップ再考
    このエントリーをはてなブックマークに追加
    こんにちは、ネットワーク事業部フルマネージドホスティング部の冨成 章彦です。
    とても地味な話題になるのですが、私はシステムの運用部門に長く携わっていて、我々の業務の中で、とても重要でありながら、いつも忘れられがちなバックアップ、ということについて、関連するキーワードの解説も交えつつ、必要性や手法など様々な面で掘り下げてみたいと思います。

    ITに少なからず関わっていれば、データをバックアップしておくことの重要性は良く知っていると思います。しかし、実際の日常でバックアップについて真剣に考える機会は少ないのではないでしょうか。この時代に今更バックアップの話、と感じる向きもあるかもしれませんが、世の中が全てクラウドコンピューティングになったしても、なお、我々は、手法は変わりながらも、バックアップの必要性から完全には解放されないと考えています。

    バックアップの必要性 - データは時々失われるという前提


    誤操作などによるファイルの消失


    ほとんどのケースでインターネットサーバのデータはHDD上に保持されています。そこに何らかのファイルシステムがあって、ファイルとしてデータが存在しているということが多いと思います。そのファイルは様々なコマンドなどの操作で簡単に失われます。rm による誤削除はもちろん cp mv tar そしてシェルの出力リダイレクトなど、ファイルの作成先を既存ファイルと同じ名前にするだけのことです。GUIで操作していれば、なおさら不測の事態が生じます。

    我々は、プロとしてシステムの運用をしてお客様に対価をいただくサービスを提供していますが、それでも残念ながら作業ミスを起こす可能性は必ずしも小さくなく、人間が行なっていることなので、スキルがどれほど上がっても絶対はありません。そして、操作によって"動作上正しく"ファイルが失われた場合、後述のHDDのRAID構成など何の役にも立ちません。

    サービスの可用性向上のために フェールセーフと作業ミスの削減の努力とその先


    作業ミスを完全になくすことは不可能と言っても良いほど困難で、決してなくならない課題ですが、当然、我々もプロとして運用サービスをお客様に提供している以上、ミスの軽減に日々勤めています。

    ただ、ミスをしない努力をしていると言っても、ミスをしない前提でシステムを設計することはあまり賢い選択とは言えません。アウトソーシングでそういったリスクを軽減しつつ外部に移転してしまうのは良い考えですが、専門でサービスを提供している我々は、そのアウトソーシング先であるので、残念ながらその選択肢はありません。

    逆の考え方で、ミスをしないシステム設計、つまりフェールセーフな設計をすれば良いとは言っても、原子力発電所の制御システムなどであれば別ですが、残念ながら多くのシステムではそれが生み出す便益に対してコストがとても見合わないでしょう。フェールセーフまではコスト的に難しいことを重々承知しているので、我々は、長く運用サービスをやってきた経験の中で培った、ベストプラクティスとまでは言えないにしても、コストに見合うようなちょっとした知恵の結集で、作業ミスを起こしにくかったり、起きた時の影響を最小限に留めるための、バックアップを含めた全体のシステム構成や運用の設計をお客様ご提案しています。

    我々の説明が至らず、ご採用いただけないこともしばしばありますが、その点もミスの軽減と同様に、結果的にお客様のシステムの可用性を高めてご満足いただくため重要なことなので、ご理解いただける努力を重ねていかなければならないことだと感じています。

    ミスの軽減と設計での防御と、もう一つ忘れてはいけないのが、何か事故が起きる前提で、起きてしまった時のフローを平時から意識しておくことです。コンティンジェンシープランニングと言うとちょっと大げさですが、常にある程度頻度の高い事故は、その後の対応フローを想定しておくことで、本当に発生した際に、冷静に対応でき、対応時間を短縮できると共に、2次的な障害を引き起こす可能性を大きく軽減できます。

    日常的な作業ミス削減のためのフロー改善、作業ミスを起こしにくく起こった際の影響を軽減する設計、そして、事故が起きた際の対応を平時に考えておくこと、この3つの組み合わせでサービスの可用性を高めるということが、無停止のシステムを考えるといったことを目指すより現実的に重要だと考えています。

    ハードウェア故障によるファイルの破損や消失


    ハードウェアは故障します。代表格としては非常に高速に回転しているHDDで、他の部品に比べて高い頻度で故障します。HDDが壊れて全てのデータを失ったり、あるいは一部のファイルが破損したり、といったことは少なからず経験したことがあるのではないでしょうか。

    ここで、すぐに思いつくのはRAID構成でしょう。多くのシステムでRAID1やRAID5などの耐障害RAIDが採用されていますが、これとてバックアップを不要とする技術ではありません。前述のような作業上のミスによるファイル消失には無力なのはもちろん、コントローラの故障やファームウェアのバグで、一部のファイルが破損したり、最悪の場合、全てのデータが読み出せなくなったりすることも実際に経験しています。

    RAIDコントローラを使っている場合の電源装置の故障も見逃せません。意外と知らない人も多いのですが、多くのRAIDコントローラは入出力のスピードを上げるためキャッシュメモリを使っています。そのため、不意の電源停止によって、HDDに書き込まれていないデータの消失を防ぐためのバッテリーも搭載しています。しかし、廉価なRAIDコントローラはバッテリーが別売りだったり、下手すると付いていないものもあります。

    つまり、電源装置の故障が、場合によってはせっかくのRAID構成が仇となり、直接的にファイルの破損を引き起こす可能性もあるのです。わざわざ追加のコストを負担してRAID構成を選択したのであれば、それ相応に重要なデータを保持していると思われ、例えば、入出力の多いデータベースのデータファイルに損傷があれば、そのダメージは深刻なものになるかもしれません。もちろん電源装置の故障は、バッテリーを積んでない(あるいはバッテリーが切れていることに気がつかなかった)RAIDコントローラだけでなく、HDDへ書き込み中のデータへ直接の影響を与えることも無視できません。

    HDDと電源装置の他、実はそれに次ぐ頻度でに壊れやすいハードウェアとしてメモリを忘れることはできません。実際の故障はもちろん、ECC非対応のメモリを使っている場合、考えている以上の頻度でエラーが発生していて、気がつかないうちにファイルを蝕んで、実は原因不明のファイル破損の原因となっている可能性があります。

    最も安全なRAID構成


    データの保全、ということを考えた時、どのRAID構成が最も良いのでしょう。パリティが2つあるRAID6でしょうか。実際にはRAID1が最も安全であると考えています。

    RAID1が、RAID6、RAID5、RAID0+1、RAID1+0といった良く利用される構成と最も異なる点は、ストライピングをしているかしていないか、という点になります。ストライピングをしていると、RAID構成なしにデータを読み出せません。これに比べて、RAID1であれば、最悪の場合、ディスク単体からデータをサルベージする、といったことも可能です。

    もちろんRAID1は容量的に不利な構成なので、用途によって選択する必要はありますが、容量の問題がないのであれば、RAID1+そのバックアップという形が最もおすすめする構成になります。


    経済性を考慮したバックアップの設計


    ここまで記載したような要因で、破局はある日突然やってきます。バックアップは保険と同じようなもので、その日に備えて、適切なコストの適切な種類のものを選択、つまり設計から始めることになります。ファイルが破損することでサービスやシステムが使えなくなることによる損害を考慮して、以下の3つのことのバランスを考えます。

    1. バックアップデータがいつの時点まで遡るか RPO(目標復旧ポイント Recovery Point Objective)
    2. リカバリにどのくらいの時間がかかるか RTO(目標復旧時間 Recovery Time Objective)
    3. 想定損害(遺失利益)に対してバックアップにいくらのコストをかけられるか

    これらを考慮しつつ、ここからバックアップの設計を進めていきます。

    バックアップの対象


    まず、バックアップ対象を決めます。以下のような対象から目的に沿って選択することになると思います。
    全てのデータ(ファイル)
    特定のファイルシステム
    重要なデータだけ
    設定ファイル
    データベースのデータ
    その他、特定のファイル
    ここでは、何を、だけでなく、どのくらいの時間で復旧させる必要があるか(RTO)も含めて考えることが重要です。重要なデータだけバックアップしていれば良い、と言っても、実際にはその重要なデータを利用するためのシステムを復旧させるのに長い時間がかかっても良い、ということはほとんどないと思います。もちろん、スタンバイ機があるような環境では重要なデータのみのバックアップで十分でしょうし、非常に頻度の低い障害に備えるのに全体をバックアップする、というのは冗長でしょう。

    一般には、OSや依存性の複雑なファイル群全体の復旧をする必要があるなら、それが含まれるファイルシステム全体をバックアップしておくことが結果的には個別のファイルの変更管理を行なうよりもずっと低コストになります。また、ウェブのコンテンツデータやプログラムのソースコードなどであれば、システム構成の中に別の管理サーバなどが置けるのであれば、そこにバージョン管理システムのリポジトリを作って、バックアップと組み合わせると良いでしょう。

    ただし、注意する必要があるのはデータベースのデータのバックアップです。仕組み的にはデータベースに限らないのですが、一般にデータベースで読み書きされているデータは、メモリ上のバッファとファイルシステム上のデータファイルを合わせて整合性の取れたデータとなります。データベースの場合、データのダンプやデータファイルそのものとログファイルなどを組み合わせて復旧させることが一般的で、単純にファイルレベルのバックアップを取っただけでは復旧に失敗することもあります。

    データベースのバックアップについては、利用するRDBMSの特性に合わせてシステム(OS)のバックアップとは別途検討をする必要があり、また、バックアップが取れているという状態にするだけでは不足で、特に復旧にかかる時間をきちんと考慮すべきです。もちろん、HDDのRAID構成と同じくデータベースのmaster/slave構成なども誤操作などによる正常な動作でデータが失われることには無力なので、必ずバックアップと組み合わせる必要があります。

    頻度と方法と世代


    バックアップの頻度は、前述のRPOに大きく関係するため、その点を考慮する必要があります。また、取得方法との組み合わせによってRTOにも関係してきます。

    取得方法には大きくフルバックアップとインクリメンタルバックアップがあり、さらに、インクリメンタルバックアップには差分バックアップと増分バックアップがあります。インクリメンタルバックアップは基本的に単体では意味を成さないので、フルバックアップと必ず組み合わせる必要があります。インクリメンタルバックアップはどうしてもRTOの面で不利なので、あまり変更の入らないシステムか、どうしてもバックアップ時間の短縮などで必要になる場合などを除けば、おすすめできません。

    フルバックアップを取るとして、その頻度ですが、変更管理をかなり詳細レベルまで行なっているシステムでは、大きな変更の入る時に都度取得でも十分な場合もあります。しかし、ほとんどのシステムでは、かなり高い頻度で変更が入るため、それを詳細に管理し、さらに、その情報を正確にリストア時に反映し、短時間で復旧させる、というのは困難でしょう。管理が好きな人の机上の空論に付き合うと、結果として本当に何か起こったときにはシステムの可用性へ大変なダメージを与えかねません。

    これは、ごく一般論でしかなく、当てはまらないケースも多くありますが、一般のシステムの稼動の特性から考えても、深夜帯で、バッチなどが動いていない時、1日に1度、自動でフルバックアップを取り、3〜7世代程度を管理できるのが多くの場合理想となるでしょう。

    なお、頻度を高くする場合は、世代にも注意する必要があります。RPOは、短すぎても、変更や削除される前のデータがなくなってしまっては意味を成さないので問題があります。極端なことを言えば、1分毎に3世代では、4分以上前に失われたデータが存在しなくなってしまいます。取得頻度を増やすにしても、1日に2回から4回、というところでしょう。世代は、それに合わせて6〜30世代くらいで考えるのが良いと考えられます。

    バックアップと近接する概念


    スナップショット

    あるタイミングのデータのイメージを保存する仕組みで、バックアップの一形態とも捉えることができます。一般にスナップショットは、対象と同一のハードウェア領域を使用するため、ハードウェア障害に対してはあまり有効ではありません。

    ただし、操作ミスなどによるファイルの誤削除などに対しては大変有効な対策で、他のバックアップ技術とうまく組み合わせることで、バックアップに対する全体のコストを引き下げられることが多くあります。また、変更量などにもよりますが、バックアップに比べるとシステムの性能に与える影響が小さいため、高頻度での取得が可能で、RPOの短縮にも有効です。

    アーカイブ

    こちらもバックアップの一形態ではありますが、その目的が、復旧でなく保存と参照であるという点が異なります。アーカイブは、参照の頻度や参照するまでにかかっても良い時間などにより取得や保存の方法が大きく異なるため、バックアップとしても使えたり使えなかったりするので、要件により復旧を目的とするバックアップと共用できるものがあるか検討する必要があります。

    メディアと保管場所


    バックアップをどの種類のメディアに取得し、どこに保管するかも検討します。取り扱いの容易さやセキュリティ、復旧のこと、RTOとディザスタリカバリーを考慮するのですが、システムのフルバックアップについて言えば、ここ最近のデータ量の増加状態を考えると、ほとんどのメディアが復旧させるには不適切となり、多くの場合、HDDが一次保存先となるでしょう。その上で、さらにテープやDVDに移す、ということはあると思います。

    次に、一次保存先のHDDを考えますが、同一筐体内か別筐体かを考えた場合、SAN構成である場合などを除けば、ネットワーク環境などを考えると同一筐体内がまずは有力となるでしょう。ディザスタリカバリーなどを考えると、一次保存を行なった後、さらに、別筐体、距離を隔てたところにあるデータセンターにあるサーバを二次保存先としてコピーするか、あるいはテープやDVDに移して遠隔地へ輸送するといったことになります。

    しかし、結局のところ、頻度とコストを考慮すると、同一筐体内の別のHDDに取得することで落ち着くことが多いと思います。そうすると、容量の関係などから、バックアップが1世代しか取得できないということになりますが、これは、我々の長い運用の経験上でも、実は多くのケースで十分であったりします。

    リストア方法とリストア先


    リストア方法はバックアップの取得方法と対となるものなので、ここに来て改めて考える必要はありませんが、リストアのできないバックアップなど意味がないので、リストア手順は確立は必須です。リストア手順を考える上で、リストア先を2点考慮する必要があります。

    一つはファイルレベルで復旧させるため、いずれかのサーバ、できれば実際に復旧させる先のサーバにマウントする必要があります。容易にマウントできない場合、RTOが長くなってしまうので注意が必要で、場合によってはバックアップ方法から見直す必要が出てくるかもしれません。

    次に、システムをまるごと復旧させる場合です。この場合、最も理想的なのは、バックアップからコピーでの戻しを行なうことなく、そのまま稼動させられる状態で保存しておくことになります。次点では、OSなどのインストール後、一部データのコピーで復旧する形です。これは、RTO上、OSなどのインストール時間とコピーにかかる時間を考慮しておく必要があります。

    ここで、スタンバイ(バックアップ)機を用意しておくのはOSなどのインストール時間を短縮するのに非常に良い手ですが、データだけをコピーすれば良い様に、きちんと設定ファイルや変更を双方に反映させる必要があり、運用上、非常に配慮が必要になるため、場合によっては選択しにくいことがあります。

    バックアップの実装


    試験と自動実行と検証


    設計が固まったら、実際に設定を行い、試験をします。バックアップを実際に実行して、そのデータを検証する他、当然、リストアの試験も必要で、その際に時間の計測などもしておくと良いでしょう。

    試験がうまく行ったら、次は自動実行の必要がない場合を除けば、自動実行の設定をし、実行されたことを確認してバックアップされた結果のデータを検証します。ここまで行なって、バックアップの実装の完了となります。

    最後に


    弊社のフルマネージドホスティングサービスDATAHOTELでは、標準のサーバを標準のHDD構成のまま指定OSでのレンタルでご利用の場合、弊社でローカルバックアップと呼んでいる仕組みでバックアップを取得するよう設定しています。日頃は忘れがちなバックアップの存在ですが、万一の時には非常に助かる強い味方となるものです。

    こういった、ローカルバックアップを含め、監視や障害対応などでも、これまでの10年にわたるシステムの運用で培ってきた経験と技術を、日頃気がつきにくいところに随所にちりばめてサービスを提供しています。そういった細かいことで困った経験をお持ちの方も、これからシステムを構築しようとお考えの方も、ぜひ一度DATAHOTELをご検討ください。

    データホテルへのお問合せはこちらからどうぞ
    datahotel