案件・業務の進捗記録と備忘録

「ウェブページに掲載されている広告のインプレッション数とクリック率を計測する」という案件を行うことになった。環境は、既に稼動しているIA32(Pentium!!!)シングル・メモリ512MB・linuxの計算機上で、Postfixメールサーバ+apacheウェブサーバ+MySQLサーバとして使用されている。(かなり以前に、こちらで納品したもの。定期的にアップデートは行われている)。

その環境では、ウェブサービスの一部でPHP+MySQL(innodb)が使用されている。そこに、今度はウェブページを表示させるたびに計測をさせることになるので、いくら軽快・高速なMySQLとはいえ、一日に何十万ものリクエスト毎に動作させるためには、それなりの変更が必要になるはず。

とりあえず、ハードウェアのアップグレードは不要と踏んだ(MySQLを使ってきた勘と、今回の処理内容を考えてみて、まず内部を見直してから、という判断)。

最初はデータベースの設計とプログラミング。要求がそれほど難しくないので、テーブル設計とクエリをきちんと最適化して行うことに骨は折れない。テーブル設計(インデックス含む)はもとより、データベースに対する要求とMySQLの都合にあわせた、レスポンスの良いクエリを送ることも重要。ちなみに、今回はMyISAMでデータベースを設計。データベースに情報が蓄積されていくだけのものなので(＝あとで変更等はされない)、MyISAMを採用。テーブルロックはガンガン掛かるだろうが、ロック解除待ちが入ってもアクセスする方には感じられない程度のものだろう。

次は、my.cnfを見直してチューニングポイントをセット。MySQLのチューニングは、いわゆる「お手本」的な考え方はあるものの、実際に設定する数値(メモリ割り当てなども)は、実際の稼動状態に合わせなくてはならない。動作を理解していないと、無駄なメモリを割り当ててリソース不足に陥り、逆にパフォーマンスを落としてしまったり、お手本にある通りの数値をそのまま書いてしまって、チューニングをしたつもりが効率の良さに全く寄与していなかったりと、いいことがない。

今回は、MySQLへの要求が大幅に増えるために、MySQLにはメモリの効率的利用をさせなければならない。

• key_bufferを増やす。インデックスをきちんと使っているデータベースならば、定番。


• innodbのテーブルサイズを見てみて、そこに割り当てるメモリを減らした。スレッドあたりのメモリ消費量を、パフォーマンスに影響を与えないところまで削減


• MySQLのスレッドが多数走るだろうから、スレッドあたりのメモリ容量・スレッドキャッシュ数などを見直したい。実際に走らせて見て、一番リクエストが集中する時間帯に、どの程度のスレッドが同時利用されるのかを見てから設定。


• スレッドごとの各バッファサイズを見直す。これは、プログラムの実装とクエリの内容がわかっているので、それにあわせる。主な動作は、(1)ウェブページへのリクエストによるINSERT/UPDATE・こちらはインデックスを使って軽く処理が出来るが、要求数は多い(2)案件のクライアントが様々な条件でデータ統計を見る・こちらはテーブルスキャンを行うケースがあるが、要求数は一日１回程度。この動作状況を考え、(1)のレスポンスと消費メモリを優先して、そちらに合わせてバッファサイズを小さく設定、実装メモリ内で並行した多数の要求が受け付けられるようにする。(2)では、なるべくMySQLの関数やソートを使ってやらせないで、取得したデータをPHPの方で要求に応じて出力を行う。これをポイントとした。
  

こんな感じで実稼動させながら何度かチューニングをしてみて、MySQLの状態とシステムの状態を平行して観察。MySQLのスレッドがシステム全体のメモリを圧迫している様子もないし、レスポンスも軽快そのもの。ということで、相当ロースペックなマシンで要求に応えられた。クライアントには詳しいことは解らないだろうけれども、なんとなく満足。

業務用のサーバではありませんが、私が稼動させているMySQL4サーバーのパフォーマンスを測定してみました。

パフォーマンスを決める要素は、

●サーバ自体の設定(スレッド数・処理メモリサイズ・キャッシュなどのシステム変数)
●テーブル構造・インデックス
●クエリ

が関わってきます(※64bitカーネルなどなら、適切なビルドを用いることももちろんです)。これらが最適になるように計画して稼動を開始したので、それが狙いどおりであれば、いいパフォーマンスが出るはずです。それを確かめるのが今回の目的となります。

当方でMySQL4が稼動しているサーバは、並列でApache・Postfixも稼動していますが、小規模なサーバではそのようなケースも多いと思いますし、なにしろ相当古い計算機でもあります。いくらなんでも今時こんな低クラスのサーバは何処へ行っても買えませんが、古いものでもどの程度のパフォーマンスが出せるのか・という参考値としてご覧下さい。

■計算機のスペック
　i815 / Pentium!!! 733MHz / PC133 SDRAM 512M / IDE SoftwareRAID1(MD)
　Apache 1.3 / request 20,000 - 100,000
　Postfix 2.1

MySQLは外部からの接続が殆どで、ローカルのApacheなどからは呼び出されていません。データベース数は３つ、うちテーブル数は５つ(MyISAM=3/InnoDB=2)、おおまかですがカラム数(フィールド数)は10-50・ロウ(レコード数)は10,000以下くらいです。

まず、サーバの稼働時間ですが、現時点で247 日, 15 時, 26 分 34 秒となっています。この間、テーブルを変更・追加などはしていませんので、パフォーマンスを測定するのには十分な期間です。

MySQLへの接続数は7,663,183、１時間あたり1,289.35接続がありました。
要求クエリ数は、毎秒1.44クエリとなっています。但し、外部からの要求は同時に連続して10以上の接続とクエリ発行が来るシステムになっているため、密度はばらつきます。

それでは、パフォーマンスの参考値としてステータスを見ていきすが、ステータスの値によって、冒頭に示したパフォーマンスを決める要素の、「どの部分は適切で・改善するならどの点なのか」を見ることが出来ます。

起動してからの総クエリ数 = 30,798,128　起動してから、これだけのクエリが送られています。この数値とステータスとの対比が判断材料の一つになります。

Created tmp disk tables 0
このステータスに限らず、メモリ＆ディスクへのテンポラリテーブル作成はゼロでした。もっとも、テーブル結合をしているクエリが無いので、それも理由になります。

Handler read first 11484 ← インデックスのフルスキャン
Handler read key 17797594 ← キーに基づくレコード読み込み
Handler read next 26107115 ← キー順序での次レコード読み込み
Handler read rnd 1095850 ← テーブルのフルスキャン
ランダムでロウを選択する・カラム値とランダム値が同一のロウを得るようなクエリも投げているので、全体スキャンも発生していますが、概ねインデックスの貼り方が良かったと判断できます。

Key read requests 32669452 ← キャッシュ内からのキー読み込み要求
Key reads 210 ← ディスク内からのキー読み込み要求
キャッシュのミス率は6.4280233411934794620981092673363e-6、キーバッファが適切に割り当てられ、機能していることがわかります。

Open tables 22 ← 現在開いているテーブル数
Opened tables 145 ← これまで開いたテーブル数
稼働時間・要求数に対して、非常に小さな値ですので、テーブルキャッシュのサイズが適切に割り当てられているようです。

Table locks immediate 15361607 ← テーブルロック要求で即ロック実現
Table locks waited 7672 ← テーブルロック要求で待ちがあった
MyISAM・またはクエリで明示的にテーブルロックを指示した結果数です。専用サーバではなく、同じテーブルに対して連続して読み書きのある要求が多い中で、この結果が出たということは、クエリとテーブル設計・インデックスが適切であることを示し、この結果は良好だと考えられます。

Threads cached 15 ← 現在動作して処理待ちをしているスレッド数
Threads created 74 ← これまで作られた最大スレッド数
Linuxの場合、一つの接続を一つのスレッドで処理しているようですので、これまでの稼動の間に、並行で74の要求を処理したことがあったようです。

さらに参考までに、40のカラム・500のロウを持つテーブルに対して、varchar(255)でカーディナリティの高いカラムを昇順でソートした結果を得るための時間を出してみます(このカラムはインデックス化されています)。

SELECT * FROM `footable` ORDER BY `HOGE` ASC

このクエリの結果は、0.0026 secで得られました。

上記によって、自分の行ったテーブル設計やクエリ最適化がうまくいっていることを確認できたことが嬉しくもありますし、同時に、こんな古臭い計算機でもこれだけのパフォーマンスを叩きだすMySQLの凄まじい速さに、改めて驚きを禁じ得ません。

手元で使用しているlinuxサーバのリプレースを思い立ちました。こういった場合、一般の企業でサーバを社屋・またはデータセンターで管理しているならば、その用途や事情に合わせてハードウェアメーカーのブレードサーバや高可用向けサーバなどを購入してリプレースすることになり、OSの導入から始まって、使用環境の整備・データの退避や復元など、費用の掛かる一大案件になるのですが、当方の場合は、小規模なサーバ群を組み直す規模です。それでも、かなり慎重に事を進める必要があります。

リプレースの理由は、老朽化機材の交換・カーネルでの構築・各サーバソフトのバージョンアップです。また、最近は省電力機能を備えたCPUがほとんどですので、そういった面も考慮したいと計画しています。と言いますか、むしろその点でリプレースを思い立ったのです。

少し脱線して、サーバ市場での省電力動向について。省電力サーバは以前よりもいっそう重視されるようになり、クラスタリングなどの環境下で、電力消費と熱を抑えるために、省電力化されたCPUを使用したモデルが、今まで以上にベンダー各社からアピールされてきています。電力消費が大きければ、発電資源の消費（＝電気コスト）の増大は避けられず、また伴って発生する熱による、部品の動作不良・損壊が懸念されます。同じ動作が省電力で得られるならば、熱を持たない分、サーバ設置環境に優しく、ついでに地球環境にも優しいという状況が生み出せます。

更に脱線しますが、通常利用するクライアントPCにも、省電力は効きます。といっても、普通に買ってきて使っていると、そういったことは全くわかりませんし、気にも留まりません。これが、ワットチェッカーという電力計測機を使ってみると、色々な電気製品がどの程度電力を使用しているのかがW(ワット)数でわかり、出来るだけ無駄な電力を下げてみたいという気持ちになります。

今、このエントリを書くのに使用しているPCは、AMDのOpteronというサーバ向けのプロセッサを搭載したPCです。このPCには、出来る限りの省電力化を行っています。何も考えずに使っていると、ただ通電しているだけで皮相電力130W・有効電力100Wの電気を消費しますが、それを、通電しているだけの状態のときには電圧とクロックを下げるようにすることで、有効電力60Wまで落としています(※もしサーバ用に使うとすれば、部品を減らして電力をもっと減らせるでしょう)。更に電源を品質のいいもの(力率と変換効率の良いもの)に交換したので、皮相電力と有効電力の比率が1:0.99になり、皮相電力との差分の無駄を抑えることが出来ます。今のように地球温暖化への懸念・またエネルギー資源の石油が暴騰している状態だと、「電気代」というお金の問題もなんですけれども、環境のためにも少しくらいは消費電力を控えたいと言う気持ちになりますね。

本題の、当方のサーバリプレース計画に戻ります。linuxの場合、cpufreqdというデーモンを常駐させ、CPUの負荷率を監視させることによって動作クロックと電圧を自動的に制御することが出来るようです(※適当な時間が無く、まだ実験していませんが)。つまり、サーバが忙しくなるとクロックが上がり、すばやく処理をこなす。暇なときは、低い電圧とクロックで、出来るだけ電力を抑えている。こういう仕組みです。力の入れどころと抜きどころのあるサーバなんて、ちょっと面白そうな気がしませんか？実際にサーバーを組む際に、レスポンスと電力のバランスを考えて設定してやれば、いい出来になりそうです。ハードウェア構成・部品の調達から始めて、2008年には新しいサーバを稼動させたいと思っている次第です。

「古いものを大事にする」ことは、多くの場合に美徳の意図を持って使用される言葉ですが、電化製品に関しては必ずしもそうではありません。例えば、エアコンや冷蔵庫などは技術の進歩により、消費電力を下げた上で更に性能もアップしています。２０年前のエアコンをぶん回すとすると、性能の低さと劣化でなかなか冷えず、そのくせ消費電力は今時のエアコンの何倍もの電気を使ってしまう…ということになります。ずっと電気を付けっぱなしで、ある意味サーバと似ている冷蔵庫も、最近の製品のほうがはるかに低い消費電力で稼動しています。買い換える際には、家電リサイクル法で古い資源を再利用還元することが出来、ごみを無駄に増やすことにもなりません(※しかし、消費者がリサイクル費用を負担する為に、不法投棄の問題が増えることや買い替え促進につながらないところが残念ですが)。

ケチという言葉の響きには、「合理性を欠く」「本末転倒」というニュアンスが漂います。今の状況をよく見渡して上手に合理化を図ることは、当方でやっている仕事にも通じます。貧乏性で何も見えずにただただ金をケチって、最終的には時間と資金をドブに捨てるのと同じことになってしまった、そんなケースも聞きます。もし、過去にそういう失敗をしてしまった方がこの文章をたまたまお読みになっていたら…「本質的な部分に気づかない」「チャンスに弱い」「力の使いどころがわからない」「ケチが災いして結局つまらない無駄遣いをしてしまう」…そんな点を、振り返ってみてもいいかもしれません。私は、そういう失敗が多かったので…

長い間使っていたサーバを新しくしました。１月前半の作業割合としては、このサーバ更新がかなりを占めたのですが、どのような理由にせよ、サーバを換えるにはコストが掛かります。linux関連の記事では、サーバを替える際の技術情報が多く取り扱われるのが通例ですが、この記事では、経営者や部門責任者を対象に、「コスト管理」について、当方でのリプレースの流れを追いながら、さまざまなケースを併記してみたいと思います。

サーバを換える理由は？

• 機材の老朽化対策(※壊れていたわけではありませんが、連続で３年程度稼動していました)
• OSの基本(カーネル)、各種サーバソフトウェアのアップデート

1. 機材は古いが、ハードウェア監視情報・目視による検査では、異常の要因は見つからない
2. ただし、サーバのハードウェア自身が古いために、更新でランニングコストを下げることが出来るだろう。
3. 同時に、明らかなパフォーマンスの向上が見込める
4. メンテナンスモードに入っているソフトウェアが動作している。それをバージョンアップするためには、基本のカーネルからのアップデートが必要となる
5. 以上から、サーバの変更を実施することに決定する
6. では、リプレースのコストはどうだろうか？機材調達については●●円
7. では、リプレースに伴う実務、コストの発生と損失見込はどうだろうか？

サーバを換えるために、どういったコストを見積もるか？

1. 直接担当者(※自分)の能力であれば、最終的に稼動が完了するまで4時間@1人×5日、更に検証や調整などに2時間@1人×3日程度で完了するだろう
2. サーバリプレースは直接利益を出さないが、その期間に対する直接担当者(※自分)の間接作業として実施できる
3. 計画の上では、リプレース業務に携わっている間、直接担当者(※自分)の他業務には支障が出ないと予測できる、即ち損失はほぼ無い
4. サーバに依存している直接利益は損なわれない(ゆらぎ範囲である)

「予測できない」問題とコストの発生があることを「予測する」

問題を発生させないために

• コスト算出をきちんと行う。出費はコストに含まれますが、出費＝コストではありません。
• 必ず着手前にプランニングする
• 担当内容の役務を明確に

参考までに。当方が入れ替えたOSはCentOS5.1(32bit)＋RAID1による冗長化、メールサーバはPostfix2、データベースはMySQL4→5、ウェブ関連としてApache1.3+PHP4→Apache2+PHP5です。バージョンの変更に伴って、データベースのダンプと読み込み・PHPコードの若干の書き換えの手間などが若干発生しましたが、昔からの情報収集や準備によって慌てることもなく完了できました。気になっていた消費電力は50W→37Wとなり、また新しいハードウェアによる底上げで、サーバのパフォーマンスが向上しました。心なしか、sshで接続していてもレスポンスがいいような気がします。

現在、2.5inchのハードディスクx2でRAID1を組んで稼動しているサーバがあるのですが、このサーバにはsmartmontools(smartd)をインストールして、ハードディスクの情報を定期的にチェックするようにしています。モニターの結果は、/var/log/messagesに書き込まれるようになっています。この結果を見てちょっと困っているのが、load_cycle_countの回数が非常に多く、健康値？が毎日ガンガン下がっているのです。このままでは、いずれエラーを吐き続けることになってしまいます。なにゆえ、この回数が多いのだろうか？対処をしなくてはなりません。

smartのload/unload cycle countは、ヘッドが円盤上からリトラクト(退避)位置に戻ったことを表わしています。この動作は、省電力機能などで行われ、普通に使っている際には発生しません。ちなみに、使っているハードディスクはHitachi HTS541260H9SA00(5K120 SATA1.5G 60GB)です。まず、当方で思ったのは、リトラクト回数が多いのは、ハードディスクに実装されているAPM(Advanced Power Management)の設定によるものかと思いまして、Feature Tools という設定ツールを使用して、省電力機能をオフにしようと考えました。しかし、家中のあらゆるPCやSATAカード、果てはSATA-IDE変換カードにまで、どんなSATAポートにつないでFeature Toolsを起動しても「APMが実装されていない」という旨のメッセージが表示されてしまいます(他の情報は見える。APMだけが「無い」と表示される)。今まで、HGSTのハードディスクを随分たくさん買ったのですが、Travelstar 5K120のSATA版だけ、APMを制御できないのです(※これ、当方の環境だけなのでしょうか？5K120のSATAでもフィーチャーツールが使えた方、もし情報をお持ちなら、宜しければメールなどで教えてください…)。

そして、更に考えてみました。このサーバのファイルシステムは、全てext3でフォーマットされています。ということは、ジャーナリングが働いているので、５秒に１回くらいはディスクへのアクセスが発生します。省電力機能などでヘッドがリトラクトする場合、ディスクへのアクセスが何分間か無かった時に行われます。このサーバでは、MySQLやらhttpdやらが常時動いていて、更にジャーナリングも行っているわけですから、基本的にディスクへの書き込みアクセスが何分間も無いような状況は考えられません。にも関わらず、なぜヘッドのロードやアンロードが起きているのか？これは、疑問のまま残ってしまいました。

そして、最後に一つ思い当たったのが、smartmontools自体の動作についてです。こちら、ソースも何も読んでいませんし(※そもそも、ATAのコマンドも知らない当方が読んでも、良くわからないだろうから読む気にもなれず)、思いつきなんですが、「もしかしたら、smartd が情報を読みにいく際に、ヘッドを退避させるコマンドを送っているのではないだろうか？」と、ふと考えたのです。現在、smartd はデフォルトの設定どおり、30分に1度、smartを読みにいきます。そこで、それを24時間に一度にしてみました。これで、ログにどういった結果が現れるのでしょうか？ こちらは、現在実験中です。何ヶ月かしたらわかると思います。

このとき、ちょっと躓いたのが、チェック間隔の設定です。/etc/rc.d/init.d/smartd に、smartをチェックするインターバル(間隔)を設定するのですが、どうもこれが反映されない。smartd_opts="--interval=86400" という記述をすれば、/etc/{default,sysconfig}/smartmontools might override だそうですから、オーバーライドされて有効になると思うのですが(※シェルスクリプトもそのようになっていますし)、might が曲者なのか？設定が有効になりませんでした。仕方が無いので、/etc/sysconfig/smartmontools のほうに -i 86400 とオプションを記述して動作させています。

※8/11日追記。いろいろ情報を漁ってみると、どうも2.5インチのハードディスクは、ノートなど動かす環境での使用が前提の為か、振動への対策などの理由で、適当な間隔？で勝手にリトラクトを行うみたいです。ブレードサーバ向けなどに、連続稼動を想定した2.5インチハードディスクという製品があるので、サーバ用途にはそちらを使った方がいいんですね。ということで、全く役に立たない記事になってしまいました。

MySQLのチューニングは、多くのデータベース開発の場で必須の知識です。が、単にmy.cnf等で設定するパラメータのチューニングだけを考えていても、必ずしも良い結果を生むとは限りません。よりパフォーマンスの高い状態でMySQLを動作させるには、稼動させるサーバの状態や、メモリ管理そのものを知っていなければならないでしょう。

ご存知の通り、MySQLは登場当初から高速な動作で高い評価を得ています。もしMySQLのパフォーマンスが悪いと感じられるのであれば、一番最初から既に間違っていると考えて構いません。CPU/メモリ/ストレージなどサーバー能力の見積り・テーブルの設計・ストレージエンジンの選定・テーブルの設計・クエリの投げ方など、これらを決めて導入・設計した企業のミス＝MySQLをうまく動かせない・と申し上げてもいいんじゃないかと思います。

それでは、MySQLのパフォーマンス向上の為に、もう少し突っ込んだチューニングのヒントは何か？を、表題にある「仮想メモリ」と絡めながら考えてみましょう。Linuxに限らず、現在主流のCPUに対応するOSは、プロセスを「仮想メモリ空間」にアドレッシングして実行しています。もし、PCに1Gのメモリしか搭載していなくても、一つのプロセスは4Gバイトのメモリ空間を独自に持っています(※32bitの場合。また、ユーザーエリアとしては4G全部使えるわけではない)。基本的に、このプロセスが持っているメモリ空間(の一部)を、実メモリに再配置して実行しているのが、現在のOSです。

間違えて思い込んでしまう一つの例として、「ハードディスクのスワップ領域にプログラムやデータを退避させ、必要になったらメモリに読み込む」ことを、仮想メモリ管理だと思ってしまうことがあります。ですが、これは仮想メモリ管理のうちの、一つの技術です。スワップが発生するのは、「稼動しているプロセス(群)のプログラムやデータが実メモリに配置されつくしてしまい、やむなくハードディスクを利用している」状態であると考えた方が、正しい理解になります。確かに、昔のOSでは常にそのように動作するものがありました(※実メモリ上にプロセスのメモリを全て配置しようとするメモリ管理のやり方)。しかし、現在の仮想メモリ管理では、メモリ活用の効率化が進み、メモリ連続性の確保など、もっと進化した方法が取り入れられています。

ですから、仮想メモリ管理を知らずにMySQLでチューニングを考えてしまうと、「あまりバッファを割り当てすぎると、すぐにページアウトしてしまってパフォーマンスが逆に落ちてしまうのではないか？」などの心配が出てきます。が、仮想メモリ管理がどのように行われているかがわかれば、バランスを考えたチューニングが可能になります。サーバの選定やパフォーマンスを最大に出すことについては、データベースの利用目的・想定されるアクセス量・MySQLを使用した上での経験則など、個人の所有するノウハウに関わってきます(ので、ここにあまり詳しく書くことは出来ません)。

先に仮想メモリの話をしましたが、実メモリ(一時記憶)にマッピングされて、実メモリだけで実行されている状態が、もっともプロセスの動作パフォーマンスがいいことは当然です。そこで、「サーバの実メモリと動作するプロセス全てを考慮して、MySQLが最も効率よく動作するメモリ配分」をロジカルに探すことが大切になります。「ハードディスクを早いものに交換しよう・RAIDを導入しよう」「CPUを高速なものにしてみよう」「メモリを増やしてみよう」などのハードウェアによるパフォーマンス向上アプローチは、確かに効果をもたらしますが、それらは、はっきりと“ハードウェアが足を引っ張っている”ことが明らかなときに実施されるべきであり、まずはMySQLが稼動しているサーバの動作状況を見直すことが、先手だと思います。

では、サーバの何を見ればいいのか？ヒントとしては、プロセスがどのようにメモリを使用しているかを調べることです。もし、MySQLのパフォーマンスが低く、尚且つMySQLが十分なメモリを使用していないのであれば、my.cnfでバッファを増やせば、パフォーマンスの底上げが出来る可能性があります。同様に、パフォーマンスが悪いにもかかわらず、MySQLに対してメモリが十分にマッピングされているのであれば、MySQLに指示しているバッファの割り当てのやり方に問題があると考えることが出来ます(※無駄なバッファに多くメモリを割り当ててあり、肝心なところにメモリが使われていない等)。

もし本当にパフォーマンスを上げようと考えるのであれば、“MySQL 高速化 チューニング”などでググったパラメータを、そのまま書き込んでも意味がありません。MySQL:サーバパラメータのチューニングのマニュアルに書かれている値や、「このパラメータには、だいたいnMバイトくらい割り当てればいいでしょう」などという情報には、自分で使う環境に関しては全く根拠がないことを、理解しなければなりません。my.cnfに設定するパラメータや値については、MySQLのshow status;コマンドで当たりを付けることが出来ますので、そこで調整を取る必要があるでしょう。

ということで、具体的に高速化をするには、それぞれの使われ方でそれぞれ最適な値がある・というまとめになってしまい、本当にMySQLの動作状態を見るなら、当方が実際に見てみるしか正解は出せないのですが、ちょっとだけ有効なヒントを出してみます。仮想メモリ管理と併せてサーバパラメータのチューニングを考えるなら、設定する値に、実メモリを意識しすぎてケチ臭い値を与えるくらいなら、ガバッと大きめの値を設定する方がまだマシなのです。もちろん、大きすぎる値はそれこそメモリのスワップアウトを起こしてパフォーマンス低下になりますが…。

MySQLのチューニングは奥が深いので、クエリキャッシュやキーバッファ・ソートバッファなどに設定する値だけを気にするのではなくて、サーバのメモリ環境全体を見通してチューニングを行う必要があります。サーバが効率的に動いている状態を見るのは、気持ちのいいものです。IT業界の悲惨な労働環境が伝聞されますが、単なるつまらない仕事にしないために、こういった点も面白がって勉強する人は貴重な存在です。そういう人を、IT業のトップはすり減らしてはいけませんね。

最近のITキーワードとして、「仮想化」があります。一つのPCで、複数のOSを独立して動かす技術です。今日、ふっと仮想化を利用したアイディア？を一つ思いついて、色々と検討していました。当方の考えたアイディアは「お遊び」の発想なのですが、思考の流れを並べてみますね。

1. バックアップを時系列で保存しているハードディスクが、複数溜まってしまった
2. それらは、それぞれ単一のディスクにしまってあるのだが、RAID5で冗長化したくなった
3. しかし、わざわざファイルサーバを改めて用意するほどの用途でも、使用頻度でもない
4. 手元にあるWindowsXPをインストールしたPCで何とかならないだろうか？
5. しかし、このPCにはRAID5を構築できる機能が無いし、RAID5のカードを買い足すほどの用途でもない…
6. また、バックアップ時以外には、うるさいハードディスクの電源は入れておきたくない（今はほぼ無音なので）
7. なんとか、今ある機材だけで、RAID5を構築する手は無いか？
8. そういえば、ハードディスクのリムーバブルケースは余っているな。これで、使っていないときにディスクの電源は切れる
9. じゃあ、後はRAID5を作ればいいから、LinuxのmdadmでソフトウェアRAID5でもやろうか
10. でも、デュアルブートにしちゃったら、WindowsXPからアクセスできないじゃないですか…
11. よし、ならWindowsXPの上でVMwareを動かして、その仮想マシンの中でRAWデバイスのRAID5を構築しよう
12. それで、Sambaを入れれば、XPから仮想ファイルサーバとデータをやり取りできる！

…と、ここまで考え、500GBx3=1TBのRAID5ストレージを作って運用し、ファイルサーバがいらないとき(使用時間の大部分)は、ハードディスクの電源も切っておけるし、仮想マシンも起動する必要なし・ということで、なんかいいアイディアのような気がしました(笑)。普通だったら、ファイルサーバを用意するものなんでしょうけれども、貧乏くさいというか、仕事柄、無駄を作らないソリューションを突き詰めてみたいというか…。自分の環境ですから、こういったやり方も面白いということで、暇を見つけてやろうと思っています。

ところで、仮想化の真のメリットってなんでしょう？VMwareはじめ、Xen・Hyper-V・AMD-V・VT-xなど、仮想化を提供する技術は増えてきています。そこで、仮想化を使った各ベンダーの推す、仮想化を利用したITソリューションのメリットを色々と読んでみたのですが、今ひとつピンときません。

何でピンとこないかというと、「仮想マシンを導入するメリット」については、確かに色々と謳い文句が語られるのですが、「仮想マシンが絶対に必要なシーンは何か？」の提示が、ほとんど見受けられないのです。どころか、プレゼン資料では、「高可用性」「自動化」「生産性向上」など、かなり無理なところにまで結びつけているような気もします。

まず、メリットとして多く言われているのは、「実は、稼動しているサーバのCPUパワーのほとんどは遊んでいるから、その遊んでいるCPU時間で仮想マシンを動作させれば、無駄を抑えることが出来る」という点です。確かに、物理サーバーのなかに仮想サーバを複数置けば、場所などのコストが小さくなります。サーバー統合ということで、管理面も一つのPCで全部を見ることが出来るので、楽になりそうに思えます。

しかし、仮に遊んでいる部分があったとしても、遊んでいるのはCPUパワーだけです。バス・ハードディスクなどの低速なペリフェラルは、CPU以上に働いています。CPUが遊んでいるということは、何か仕事があったらフルにぶん回せる、余裕のある状態だともいえます(※もしかしたら、かなりの企業がオーバースペックのサーバを買ってしまった・もので、CPUが遊んでいる状態かもしれませんけれども…)。とまれ、もし仮想マシンがプロセスとして増えたら増えた分だけ、新たにOSを動かす負担が掛かります。OSを動かす＝単なるプロセス以上にハードディスクやメモリなどのI/Oを酷使することとも言えますので、それぞれの仮想マシンのパフォーマンスは落ちてしまいます。I/Oの負担増に関しては、仮想化のデメリットとして多く触れられていますので、「ハードディスクを仮想マシンごとに分ければいいじゃない」「CPUをすごいのに変えればいいじゃない」「NIC挿しまくればいいじゃない」というソリューション？も答えにありそうですが、それは、結局ある程度のコスト負担が発生しますね。

次に、サーバを仮想マシンで統合する点について。サーバのソフトウェアやシステムには色々あるので、一概には言えないのですけれども、「仮想化する必要があるの？」という疑問が生じてきます。ソフトウェアが余程ひどい作りで、常にCPUタイムを食い尽くすようなものであれば、仮想マシンで分けてしまうのも手かもしれませんが、仮想化ソフトウェアがCPUロードをコントロールできるのと同じ・ないしは、それ以上のレベルで、サーバのプロセスもシェアリングを行っています。プロセスが同じサーバで動いていれば、そもそも統合化という考え方にはなりません。ですから、仮想マシンを動かして、その下のプロセスとしてサーバソフトを動作させるよりは、普通にホストOSのプロセスとして走らせた方が、高速ですし省電力でしょう。また、サーバを分ける大きな理由となるデータベースのレプリケーションや、ラウンドロビンなどは、仮想化で統合というアプローチには、たどり着きづらいと思われます。ただ、「ウェブサービスは絶対にIISじゃなきゃいやだ・でも、DNSはFreeBSDじゃなきゃいやだ・データベースは、Linuxで動いているPostgreSQLじゃなきゃいやだ」みたいな設計を出されたら、仮想化の魅力はありますね。

そして、フェイルオーバーに関して。仮想化で提示されるメリットにおいて、仮想マシン内でのOSやプロセスのクラッシュが、ホストOS・他の仮想マシンに影響を与えないことが強調されますが、実のところ、普通に設計して運用しているならば、OSやプロセスがクラッシュするよりも、ハードウェア障害の方が余程起こりやすいといえます。通常、壊れやすいハードはハードディスクとマザーボードなので、大抵は予備を持っています。例えば、Webサーバが壊れても、そのサーバ以外は生きていますから、いじる必要は無く、故障したウェブサーバの機材交換とチェックだけで、すぐサービス提供の状態へ復旧できます。しかし、統合された1台のサーバが深刻なハードウェア障害に見舞われたら、仮想化されている全てのサーバ機能がダウンしてしまいます。確かに、仮想マシンはハードウェアへの依存が低い(※ほぼ無いかもしれません)ので、どんな代替機にでもすぐに移し変えることが出来るのですが、結局、各仮想サーバのバックアップ(ないしはスナップショット)は作らなくてはなりませんし、各仮想マシンの、クラッシュ状態はどうか・ファイルシステムは無事なのか・データの不整合は生じていないか？などなど、それぞれの仮想環境の確認と復旧には、結構な手間とパワーが掛かるように思います。そう思うと、仮想化によるサーバ統合化は、リスクやダメージも統合化されてしまうのではないか？と、考え込んでしまいそうです。

他にも、コンピューティング環境の破壊や、ウィルスなどの感染に対処するために、クライアント用途で仮想マシンを使用して作業をする利用例もありますが、仮想PCは、ビデオなどのデバイスへの出力はそれほど早くないので、GUI等の環境では、かなりじれったいかもしれません。

と、ここまで、仮想化をビジネスと結びつけるメリットと、それについての私的な考えをつらつらと書いてみたのですが、仮想化については、ハードウェア進化における「省電力性」ほどのアピールを感じさせてくれるわけでもないし、「本番の使用にも十分耐えうる」など、逆に心配になるような強調があったり、そもそも「CPUが常時遊んでいるようなサーバ群を、設計構築して導入を計画したのは、どこの誰なんだよ」のような素朴な疑問がわいてきます。しかし、だからといって仮想化は余計なこと？無価値？かと言えば、そんなことは無いと考えます。

実際に仮想化を試してみた多くの人の感想は、「PCのなかで他のOSが動いていて、面白いな！」くらいの印象が、多いかもしれません。当方も、そんな感じでした。しかし、仮想化は、「プログラミングやテスト環境の構築」「特殊な状況でのデプロイメント(この場合は、環境の可搬性というべきでしょうか)」などの用途では、既に多く利用されています。ビジネスとして「頑張って仮想化のメリットを見出す」状態から、「仮想化が必要とされる状況」が見えてくるのは、もう少し先にあるのかもしれません。

冒頭に書いた、当方の仮想化の利用例は、ビジネス価値へ結びつく例としては、あまり出てこない要求だと思います。しかし当方にとっては、固有の条件を満たす、いい解決方法が得られそうだと思いましたし、仮想化の用途を考えてみるいい機会になりました。こんな、ちょっと変わった使い方への要求があれば、ぜひ聞いてみたいですね。そこには、仮想化の思わぬニーズが隠されているのかもしれません。

詳しい計画については、前回の記事をお読みください。ここまでやったことは、VMwareをインストールして、CentOSを入れて、mdadmでRAID5のボリュームを作りました。結果は成功でした。ところで、VMwareのちょっとしたTips。VMwareをインストールすると、５つくらいサービスが追加されるのですが、これの起動に時間が掛かる＝Windowsの起動が遅くなるので、VMwareのサービスは、普段は手動にして止めておき、VMwareを使うときだけ、これらのサービスを起動するようにします。当方の場合は、バッチファイル(.bat)に、net start "VMware ...." を書いておいて、VMwareを起動させる前に、そのバッチを実行してから、VMwareを立ち上げる手順にしています。

この状態から、VMware上でTrueCryptを導入してみました。以下は、そのフローです。躓いたり失敗した部分がかなりありまして、次回同じようなことをやるときは先に準備をしておく為に、躓いた点もそのまま含めて、履歴としてフローに入れておきます。

TrueCrypt 6.0aをインストールする
{
　　MacOSX/linux向けのソースをダウンロードして展開
　　{
　　　　wxWidgetsが必要らしい
　　　　{
　　　　　　wxWidgets2.8.8 をダウンロードして展開
　　　　　　configure に失敗する(gtkが必要)
　　　　　　{
　　　　　　　　yum で、gtk を入れる(configure 失敗)
　　　　　　　　yum で、gtk2 を入れる(configure 成功)
　　　　　　}
　　　　　　make する(失敗, gcc が必要)
　　　　　　{
　　　　　　　　yum で、gcc-c++ を入れる
　　　　　　}
　　　　　　(一応) configure をやり直してみる
　　　　　　make install 成功
　　　　}
　　　　Readme.txt をよく見たら、NOGUI でmake できるらしい(gtk 不要??)
　　　　X で操作しないから、GUI は要らない
　　　　make NOGUI=1 WX_ROOT=/usr/src/wxWidget-2.8.8 wxbuild(成功)
　　　　make NOGUI=1(失敗, fuseが無い)
　　　　{
　　　　　　yum のリポジトリに、rpmforge を加える
　　　　　　fuse fuse-devel を入れる
　　　　}
　　　　Main ディレクトリに、truecrypt 実行ファイルが出来た
　　　　適当なディレクトリ(当方は/root/) にコピー
　　　　どうせroot権限でしか実行できないので、実行は、~/truecrypt
　　}
}

状況をまとめます。Opteron 2.0GHz (メモリ DualChannel 2GB)にインストールされたXP Pro SP3の上で動作している、VMware server(メモリ 256MB)の上でCentOS5.2を動作させ、物理ディスク3台を使用してmdadmソフトウェアRAID5を/dev/md0に構築、そのRAIDボリュームをTrueCryptで暗号化、Sambaでそのボリュームをネットワークに繋げて、ファイルサーバとして必要なときに機能させる。

こう書くと、かなり苦しいことをやっているようですが、エンクリプトの進捗状況を見ていると、32.5Mの暗号化速度が出ています。結構早いな…というのが、正直な感想です。RAID5のパリティ計算＋暗号化の計算を、全部CPUでやっているので、CPU使用率は80%を超えていますけれども、ホストのXP上でちょっとした作業(※こんな文章をテキストエディタで書いたり、IEでのウェブブラウジング)では、ストレスは出ません。

ファイルサーバが要らないときは、ハードディスクの電源を落として、VMwareも起動させない。普通にXPだけを使うことが出来ます。当方のケースでは、まずクライアントマシンとしてXPを常用していること、ファイルサーバとはいえ実質的に保存するだけの用途、使わないときが多いためTCO(※Total Cost of Ownership ここでは、ITに掛かる全費用と考えてください)を抑えたい、こういった要素が複合して、このやり方をソリューションとして導き出し、また必要十分な結果を得ることが出来ました。

しかし、企業など複数の人が常用するファイルサーバなら、クライアントマシンに仮想マシンでサーバを入れて使うよりも、独立したマシンを用意する方が、パフォーマンス面でも安定運用面でも賢明です。IT導入は、そのケースと要求に応じた分析力と解決策が必要ですね。

ところで、ITコンサルタントって、こういった一連のIT技術を全て理解している必要がある・と、個人的には思っています。ITコンサルタントは、顧客とダイレクトに向き合うケースがほとんどですから、ソリューションについての企画立案とメリットやデメリットの提示・案件定義への理解＋現場の進捗状況の把握(※時として指示)・初期交渉からスタートする対価の折り合い付け・e.t.c.、なんでも出来ないと、コンサルタントとして機能できないような気がするのです。

とはいえ、IT企業の仲介をメイン業務としてコンサルタントを名乗る方が、仕事としても楽だとは思うんですが…。それは嫌な意味ではなく、当方のメンタリティやスキルバランスを考えてみると、仲介によってIT企業に仕事を与え、それを管理したいと考えるよりも、自分の実務スキルを以って、実際に手を出す方を好んでいるからかもしれません(※正直、あちこちを見て回る事になるので、ロスが多くてしんどいですが…)。

以前にこのエントリに記述したサーバ交換ですが、その後、１ヶ月くらいの稼動中に、突然ファイルシステムが崩壊(？)しました。ftpとsshを接続して操作中に、ふとデータベースが停止していることに気づいて調べると、データベースファイルが消えていました。理由がわからず、ディレクトリを見ていると、一部のファイルの日付と内容が、古いものに巻き戻っているのを発見。さらに色々なディレクトリを調べていると、そのうちにサーバからの応答がなくなりました。

なにが起きたのかさっぱりわからなかったのですが、原因がわからないとこの先困るので、それなりに思い当たる点を考えてみました。

ハードウェアが対応していなかった

もしそうなら、１ヶ月間も稼動できないはず。/var/dmesg を見てもおかしなエラーはありません。なので、これは考えづらい。

ハードウェアが故障した

トラブル後にチェックしたところ、全て正常のようです。

電源容量が足りなかった

これはまるっきり無関係とは言い切れません。AC電源を84w出力の製品に変更したのですが、アイドル時こそ消費電力が少ないものの、フル稼働状態ではギリギリだったのかもしれません。しかし、可能性としては低いような。

SSDのパーティショニングに失敗した

SSDはブロック単位でアラインメントをあわせないと遅いので、fdiskでそのようにパーティションを作成した後にRAIDに参加させましたが、この過程でパーティションサイズとか何らかの間違いがあったなど。しかし、ハードもOSもLBAでアクセスするはずなので、ジオメトリ(シリンダ境界の無視)が障害になるとも考えづらい。

resize2fsの操作やRAIDの再構成に失敗した

ファイルシステムの壊れ方から見て、この可能性が一番高いように思えます。resize2fsの過程で何らかの操作を間違ったか、その後fsckでチェックをかけるときに、ぼーっとしてマウント状態にもかかわらず修復オプションを切らなかったとか。この可能性が最も高いように思います。

サーバが止まった時点では、これらの原因を特定することは出来なかったので、想定できる上記のトラブル要因を切り離して再構成することにしました。ハードウェアには、世代が古くCentOS5の運用で実績のあるLGA775マザーとCPUを使用、HDD*2のRAID1にファイルシステムをバックアップから戻し、再度サーバーを構成しました。sataコントローラは以前のサーバで使用していたPCIカードをそのまま使用、電源についてはstressで負荷を目いっぱい掛けた状態の最大消費電力が45w程度であることを確認してAC電源84wを使用、ファイルシステムにはパーティション拡大などの余計なことはしないことにしました。その結果、現在ようやく１ヶ月くらいの安定稼動が続いています。

自分でサーバを作ると、いざおかしくなったときに問題の切り分けが難しく、再稼動にも時間がかかるので、クリティカル業務に使用するサーバは、やはりメーカー量産品のほうが安心ではありますね。それほど大規模ではない企業やセクションにおいて、PCの操作が出来る人が自前でサーバを立てて運用するような話も聞きますが、こういう場合の負担やロスも、危機管理として予め考慮しておく必要があるでしょう。詳しい人が、業務命令や好きだからという理由でサーバの構築や運用を行ったとしても、その後にどれだけの負担があるかまでは、初期段階ではなかなか想像できないものですから、組織内での自作サーバ運用は、やっぱりお勧めできないですね。何とでも出来る人がいれば何とでもなるでしょうけれど、トラブル時の負担はかなり重いです。

--

以下が、昨年11月に構成したときの記事です。おそらくハードやOSの動作には問題が無いと思うので、再び構成を戻したいのですが、現状うまく動いているので、今の機器構成でいこうかと思います。※ちなみに、このときに交換したコンデンサが膨れた古いマザーは、コンデンサ交換をしたのですが、今となってはなかなか使い道が無いですね。一応、保守部品として保存することにしました。

--

秋の気配も深まったある夜、これまで使用していたサーバのファンから異音がしているのに気づきました。ファンがダメになってきているなと思いつつも暫く放置していたのですが、以前からsmartdが報告しているハードディスクのsmart値が気になっていたこともあって、サーバを開けてみることにしました。

どのファンだろうと思って調べたところ、電源ユニット(SeaSonic SS-300SFD Super Versatile Plus)のファンが壊れかけているようです。いったんサーバを停止してファンを交換しようと分解したところ、なんと・大きめの電解コンデンサ全部の頭がぽっこりしているのを発見。

こりゃ電源交換か、とにかく気づいてよかったわいと思いつつ、マザーボードを見ると…これまた、CPU脇の大きい電解コンデンサの頭が何本かぽっこりとしています。

危険を感じて、2台のRAID1構成のハードディスクの一つを外してバックアップを行った後に、なんと不良セクタ発生。

当ブログの過去のエントリを見ると、このサーバを立てたのが2008年の1月。ということは、4年半以上の間、ほぼ連続稼動していたわけで、ディスクのsmart値をみると、通電時間が43,000時間以上・ロード/アンロードサイクルは838万回を超えておりました。ある意味、どの部品も非常に良く持ったというべきでしょう。

そこで部品の全交換となるわけですが、こういう場合、通常はOSを新規インストールするのが常道だと思われます。が、なんとかそのままディスクの内容を生かして新しい構成に移行できないかと考えました(※新規インストールして4年以上にわたる環境構築の再現が非常に面倒だったことと、果たしてそれが出来るのか？という興味がありました)。

元のサーバーは、SiS 741GX チップセットにMobile Athlon XP 2100+を搭載したマザーに、PCIでSATA1のディスクを繋げていたという、今時ありえない古さを誇るマシンで、ディスクには、カーネルのアップデートを重ねたCentOS5.8が入っています。ということは、そこそこ新しいチップセットやCPUでも動く可能性がある。そこで、新規インストールも覚悟の上、どうせやるなら今年の夏に発売された最新のチップセットに現在のディスク内容をそのまま載せて使ってみようと考えました。

いきなり闇雲にパーツを買ってきて組み立てて、ディスクをつなげて起動させるのではなく、調査や検証も念のために行いました。検証には、ディスクをそのままVMware Playerに繋げてみたり、Intel LGA775のPCに繋げて動作させてみました。いずれもうまく動作したので、最新のCPU＋チップセットでもいけそうだという勘が強くなりました。

いよいよパーツの選定と購入ですが、後継に選んだパーツ構成は、以下の通りです。

1. CPU: Celeron G550
   安価かつ必要十分なパワー



2. Mother: MSI B75MA-E33
   最新のIvy Bridgeに対応する今夏にリリースされたチップセット。サーバに使うにもってこいといえる、無駄な機能が無い上に32bit PCI がネイティブで接続されている優れもの。安価なのにオール固体コンデンサの製品です。同価格帯のASRockのB75マザーと最後まで迷ったのですが、ASRockの方にはASmedia?外部SATA3が付いているなど、なんかごてごてした感じがありましたので、シンプルな方を選びました



3. Memory: ADATA DDR3 XPG Gaming series 4GBx2
   別にオーバークロックするつもりも無いですが、安かったので購入



4. SSD: ADATA SP900
   ADATAのSSDを使ったことがなかったので、それだけを理由に購入



5. Power supply: AC150-AP04AA
   WIndows98の頃、電源の背面からぶしゅーと煙を吹いたことがありました。その記憶もあり、今回もコンデンサの劣化を目の当たりにしたので、固体コンデンサ＋ハイブリッドアルミ電解コンデンサ(多分)を使用したこの電源に決定

そして今回、これまた実験のような感じですが、SSDとHDDでソフトウェアRAID1を構成してみました。しかも、sda=SATA3(6.0Gbps)とsdb=SATA1(1.5Gbps)との組み合わせです。これ、予想通りというか、RAIDの再構築の様子を見ていると、やっぱり遅い方に足を引っ張られますね。RAIDメンバーからHDDを外してSSD単騎で起動すると、凄まじい速さで起動します。

ただ、RAID1では、読み出しには最初のメンバー(例えばsda)を使うという情報もあり、もしかしたら、現在の環境で読み出しは少し早いかもしれないです。体感が出来たわけではありませんが。

ワットチェッカーで電力使用量を計測して見たら、アイドルで23W。Sandy Bridge のセレロンは優秀ですね。予想以上に省電力な構成となりました。

ということで、何世代も前に構築したCentOS5環境を、そっくりそのまま最新のチップセットに持ってくることが出来ました。RHELのロードマップによれば、5シリーズは10年のサポート期間を設け、来年？にリリースされる5.9は、Sandy Bridgeへの更なる対応強化・Ivy Bridgeへの対応等を含むらしいです。

自宅で管理しているサーバのストレージを、USBメモリにリプレースしてみました。特に合理的な理由も目的もなく、単にUSBメモリやSDカードの価格が安くなってきており、興味本位の実験としてやってみたいと思っただけでしたが、その経過を記します。サーバの構成や稼動内容は、以下のようになっていました。

CPU

AMD Opteron 2cores (電圧下げとダウンクロックで1GHz動作)

メモリ

2GiB

ディストロ

CentOS 5.10 (更新を重ねた現在のバージョン)

主な用途

Apache2 / PHP5 / MySQL(MyISAM及びInnoDB) / メールやcronによるプログラム実行など

ストレージ

60GBハードディスク2台構成によるソフトウェアRAID1(linux標準のRAID)

60GBのストレージは/boot /var /tmp などをパーティションで区切り、それぞれRAIDにする構成になっています。この状態から、16GBに収まるように構造を縮小したり拡大したりして、USBメモリに入るようにします。

ファイルシステム・md・パーティションの構成を変更する方法に関しての詳細は、ネットの情報に譲るとして詳しく書きませんが、一応の流れを書きます。

1. サーバの電源を落とし、念のため現在の状態をバックアップ
2. 稼動していたハードディスクの片方を繋げたPCを、Live起動のCentOS6 で起動
3. e2fsck -f でファイルシステムのチェック
4. resize2fs でファイルシステムの大きさを変更
5. mdadm --grow でRAIDボリュームを適切な大きさに
6. Live版をシャットダウンして電源を落とし、変更を行った片方のHDDだけで起動
7. (たぶん起動時にfsckが自動で行われて)普通に起動
8. cat /proc/mdstat で見るとデグレード状態
9. USBメモリを挿す(挿しておいて起動でも)
10. fdisk でUSBメモリのパーティショニング及びタイプのセット
11. mdadm --add でUSBメモリをメンバーに追加
12. 電源を落とし、ハードディスクをはずしてUSBメモリだけで起動
13. USBメモリを挿して、先ほどと同様にfdisk及びRAIDメンバーに参加

躓いたところとしては、●パーティションの大きさ>RAIDボリュームの大きさ(persistentスーパーブロック位置)>ファイルシステムの大きさ、それぞれの値●LiveDVDでraidボリュームを操作した後、md*の番号がmd127,md126...などに変わってしまうことの対処●USBメモリのデバイス名割り当て　などなどありました。

ということで、USBメモリでの起動に関して、いくつか。

■USBメモリで起動させるにはどうすればよいのか。マザーボードのBIOSの設定を変更することが必要です。ネットにたくさん情報があります。

■USBメモリのデバイス名割り当てについて。/dev/sda, /dev/sdb...などがどのように割り当てられるのか、いくつかのマザーボードで試しました。結論としては、「毎回不定ではないが、どのように決定されるのかはudev次第である」ように思えました。USBのホストコントローラー(UHCI/EHCI)の順序(挿し位置)によって決まりそうな気もしたのですが、必ずしもそうでもないようで、現在のPCでは、USBの順番としては後のほうが/dev/sda になっています。このあたり、RAIDを組む際には、決め打ちするかUUIDなどを使用するか、判断が必要と思われます。

■起動できないUSBメモリについて。これは、当方では見たことがありませんが、あっても不思議ではありません。起動できないというか、起動するとおかしくなるものはありました。いわゆる100yenショップのダイソーで購入した白いSDカードのリーダーライター(G051との品番？表記)は、読み書きも速く、アクセスランプも付いていて非常に快適なのですが、linuxのUSB起動に使用すると、カーネルが立ち上がってread-writeモードになった瞬間におかしくなり、カーネルパニックとなります。ファイルシステムの内部も破壊されています。普通にWindowsなどで使っている分には全く問題がないので、カードリーダー内部での処理の相性やドライバとの相性などがあるのかもしれません。同じく100yenショップのキャンドゥで購入した透明の真四角っぽいリーダーライターは、遅いのですがこのような問題はなく、起動に使用できました。他のリーダーライターでも問題は出なかったのですが、このような相性などの可能性には留意したほうがよいかもしれません。

■USBホストコントローラについて。USB2.0規格の最大転送レートは480Mbps(60MiB/秒)です。チップセットによると思われますが、RAIDのようにUSBメモリを平行して複数使用する場合には、ルートハブごとに接続を分けると、読み書きの効率が若干よくなるかもしれません。

■USBメモリの容量(総セクタ数)について。今回、同じ製品をいくつか購入しましたが、同一の製品であっても、製造時期やロットによって総セクタ数が異なることを知りました。RAID1を組む場合、後から追加するほうが小容量だったとしたら、RAID1が組めません。ですので、最初にメモリ容量いっぱいで計画を立てないで、少し小さく見積もっておくほうがよいかもしれません。

■USBメモリの速度について。USBメモリでもSDカードでも、速度にばらつきがあります。当方の構成では、/dev/sdaに、SiliconPower のUHS-I microSDカード(SP016GBSTHBU1V10-SP)をキャンドゥのリーダーで接続し、/dev/sdbには、SiliconPower のUSBメモリ(Marvel M01 SP016GBUF3M01V1B)を接続しています。Marvel M01のほうなのですが、いわゆるランダムライトが非常に遅いです。Crystal Disk Mark で計ってみると、4K write 0.006MB/sなどという数値が出てきます。microSDのほうは高速で、4K write 1M/sを超えています。この組み合わせで運用してみると、ターミナルからコマンドを叩いても、不安になるレベルで反応が返ってきません。なにかを書き込んでいるときには、ハングアップしてるんじゃないかと思うくらいに動きが鈍くなります。反して高速な製品を使用すると、HDDと遜色のない動作となりました。ので、USBメモリやSDカードでlinuxを運用しようと思うなら、ネットでよく調べて、ランダムライトが高速な製品を選ぶことが非常に重要だと思いました。いわゆるLiveUSBでlinuxを動かすのであればともかく、通常の運用をする場合には、読み書きの速度がきわめて重要だと思います。

■USBメモリの耐久性と寿命について。当方では、/etc/fstabでnoatimeにしているくらいで、後はHDDと同じように書き込みを行っています。MySQLデータベースの更新でも、/var/logにも、どんどん書き込みが行われている状態でどのくらい寿命がもつのか楽しみです。Nandのウェアレベリングやガベージコレクションに興味があっていろいろと調べたのですが、その有無やアルゴリズムなど、一切が不確かなので、実際の運用状態で自分で試してみるしかなさそうです。※USBメモリやSDカードの耐久テストを行っているサイトもあって参考にしましたが、そのテストは全領域に対する順次書き込みによるものであり、read modify write や一部だけを繰り返して書き換えるような実際的な運用のされかたに関しては、どのくらいもつのか全く見当が付きません。

最後に。USBメモリでのlinuxサーバ運用は、ビジネス用途などに導入するケースはほぼ考えられないと思われます。しかしながら、継続した運用コスト・保守管理・安定性を無視できる「パーソナルユース」であれば、普段Windows で使用しているPCに挿すだけで使用でき、なおかつハードディスクのデュアルブートなどをしなくても環境を分離して保持ができるメリットがあります。USBメモリによるlinux運用は、大いに実用的だと思いました。

※追記1.
USBメモリのudev認識順ですが、EHCIはUSB機器を認識したら動的に番号を割り当てる？ので、BIOSによるハードディスク起動順などが関係してくるかもしれません。

※追記2.
Nandフラッシュにおけるパーティション開始位置の最適化ですが、イレースブロック・アロケーション等を考慮して、全て4Mbytesを境界にしてみました。

※追記3.
USBメモリのSilicon Power Marvel M01 16GB ですが、あまりに遅くて(反応が悪くて)かなわないので、一日で同じSilicon Power のUHS-I microSDカードに交換し、同じカード２枚のRAID1となりました。本文中でも触れていますが、こちらは快適。

※追記4.
Marvel M01 に関しては、購入後にいろいろありました。製品をネットで調べてみると、当方が購入したのは、とりわけ遅いハズレのようでした。サーバから取り外した後、仕方なくなんかに使おうかと思ったら、購入して何日かで何回も挿抜していないのに、USB3.0で認識しなくなりました。もともと、USBポートに挿すときに、コネクタ部分が微妙に本体にめり込んでみたり、「ぐきっ」と素直ではない嫌な感触があったので、USBコネクタ奥のUSB3.0端子部分をドライバでこじっていたら、ピンが折れました。普通はここで捨てるのでしょうが、分解してコネクタ端子を付け直すことにしようと、構造のあたりをつけて分解を試みました。が、光る尻の部分が素直に抜けると思いきや分解できる作りではなく、その部分がちぎり取れました。ともかくも基板を抜き出すと、コントローラーはPHISONのものでした。コネクタ端子の構造を確認し、aitendo(パーツショップ) で部品(50円)を購入、半田付けをして直しました。Marvel M01は、価格コムを見ていると売れているようです。NTFSでうまくフォーマットできないという話題があるようですが、それはたぶんハード的な不具合ではなく、出荷時にスーパーフロッピー形式でフォーマットされている？ので、ためしにSD フォーマッター4.0で一度フォーマットした上で、更にWindowsでNTFSにフォーマットしてみると、うまくいくかもしれません。

※追記5.
更にMarvel M01 ですが、あまりにも遅くて仕方がないので、PHISON PS2251-07-Vファームウェアの書き換えなどを模索しましたが、うまくいきませんでした。ところで、Silicon Power のグローバルシェアの詳細はわかりませんでしたが、海外オフィスを見ると、ロシア・インド・ミャンマー・日本・韓国などに展開しているようです。米欧のユーザーが積極的にSilicon Power の製品を選好しているような感じもしません。いろいろな製品が選び放題で豊かな筈の先進国・日本ですが、価格コムではSilicon Power の製品が、不評がありながらも大人気です。Silicon Power による日本への市場展開と設定がまさに成功しているのですが、マーケティングの狙いを慮ると複雑な感じもします。

linuxサーバのHDDをUSBメモリに交換の記事を書いて、USBメモリ(SDカード)によるサーバーの運営から2年少々が経過しましたので、その間の運用実績を記します。

SDカードは故障・速度低下などの全くトラブルがないまま、常時起動にての運用が続いています。書き込み量などがそれほど多くない環境下とはいえ、USBメモリをストレージに使用してLinuxサーバーを稼動させる実証実験は、十分に達成できたと考えます。

大規模なアクセス要求が発生するサーバーにおいては、NAND消耗のみならずレスポンスなどの点も含め、このようなUSBメモリによるサーバー構築をお勧めできませんが、中小企業におけるウェブサーバー程度のシステム・また部内で使用する閉じたイントラ環境など、小規模・非クリティカルな運用であれば、RAID1(10)による多重化・保守部品の用意を大前提として、USBメモリによるシステムの構築運用は可能と考えています。

レスポンス(速度要求)に関してですが、Linuxのキャッシュメモリに収まる小規模なファイルを扱っている分には、読み書き共に速度の問題は感じられません。キャッシュからあふれる細かい書き込みが発生するなどの状況では、USBメモリなりのウェイトが発生します。この点を改善するには、RAID10の構成本数を増やす・複数のUSB2.0コントローラー(一つのコントローラーは480MBpsを共有してしまう)で分けるなどが考えられます。

トラブルとしては、USBメモリ(カードリーダー)とサーバーとの相性 がありました。まず、起動シーケンスに入る前にRAID及びファイルシステム(ext4)を認識できないSDカードリーダーがありました。この場合、システムは起動できません。他にも、終了シーケンスの際にRAIDの状態を正しく保存できず、次の起動シーケンスでRAIDの状態がnot cleanとなってresyncが行われてしまうカードリーダーがありました。いずれも100円ショップで購入したものですが、接続サーバーのBIOSに対して返す情報・USBメモリへの制御など、もしかしたら起動用途には向かない可能性があるのかもしれません。

但し、私見による推測ではありますが、これらのトラブルは必ずしもカードリーダーだけに問題があるとは限らず、サーバー機のBIOSによるUSBの制御にも起因するのかもしれません。最初からブートドライブとして想定されているSSDやハードディスクでは、エンタープライズ用途でないコンシューマー向け製品を使用しても問題に遭遇することはほぼないので、この点は検討すべきデメリットと言えます。

万が一カードリーダーが壊れてしまい、交換品によって上のようなトラブルが起きた場合には、業務の一時停止や復旧などが発生します。システムを構築し、ブート・運用・終了など全てにおいて問題がないことが確認できたら、保守部品として同一品を購入・保管しておくほうが、故障時の対策として適切と思われます。

Raspberry Pi をはじめとした省電力・省スペースの小型PCも増えてきたので、あくまでもミッション・クリティカルではない小規模なシステム運用という前提ではありますが、USBメモリによる安価なLinuxシステム構築を検討してみても宜しいかと思います。