URL打ち間違いにも柔軟に対応しよう

www.○○○.comというサイトがあったとします。このサイトをWEBブラウザーで開くとき

次のような打ち間違いをすることってよくありませんか？

http://○○○.com/

http://ww.○○○.com/

http://wwww.○○○.com/

http://w.○○○.com/

等々。

こういった打ち間違いに対応するために、以下のようにDNSを設定しておくと打ち間違いにも対応した柔軟さを持たせることができます。
www  IN A            10.0.0.10
     IN A            10.0.0.10
w    IN A            10.0.0.10
ww   IN A            10.0.0.10
wwww IN A            10.0.0.10

リモートKVMスイッチの選び方

今日はリモートKVMスイッチについてです。

データセンターに設置してあるサーバでOSにネットワーク接続できない場合どうするか。例えばIP設定ミスでネットワーク接続が切れてしまったり、OSインストール中にホスト名入力等のちょっとした設定をリモートで行いたいなどといったことがあります。

大きく分けて3つの対応方法がありそうです。
(1) データセンターのリモートハンドサービスを使う(データセンターに常駐している人に電話やメールをして、簡単な対応をお願いできるサービス)

(2) DELLのidracやHPのiLOなどのリモートコンソール機能を使う
(3) リモートKVMスイッチを使う

今回はリモートKVMスイッチについて考えてみたいと思います。

【リモートKVMスイッチとは】
リモートKVMスイッチとは、その名の 通りKVMスイッチをリモートでアクセスできるようにした装置で、KVM over IPなどとも呼ばれます。製品としては、ネットワークポートがついたKVMスイッチもあれば、KVMスイッチに接続して使う、リモート接続機能だけ提供するタイプのものがあります。

【リモートKVMスイッチの選定ポイント】

いろいろなリモートKVMスイッチを使ってきて、おおよそ次のような選定ポイントがありそうです。

・リモート操作するコンピュータのコンソールはWEBブラウザ上で使うか専用ソフトウェア上で使うか。
WEBブラウザのほうが便利なことが多いですが、Java appletやFlashなどを使うタイプのものだと、最近のWEBブラウザではそれらが動かせなくなってきているのでむしろ不便かもしれません。（私はFireFox+IEアドオンで使うことが多いです）

・ずれないマウス。
コンソール上のマウスカーソルと、コンソール内のOSのマウスカーソルが一致しなくていらいらするリモートKVMスイッチが多いです。Windowsが多い環境であればずれないマウス機能は絶対あったほうが良いです。2016年現在では、Raritan社のDominionシリーズが特におすすめです。

・同時接続数
あまり使われないと思って同時接続数1で買ってみたら、意外と同時接続したいというニーズが出たりします。

レーザープリンタの選び方

レーザープリンタもいろいろな機種があって迷います。そこで今日はレーザープリンタの選び方を書いてみたいと思います。

【とにかく重要なのはランニングコスト】
カタログからレーザープリンタを選ぼうとするとどうしても目に付くのは本体価格だと思います。でも数年のスパンで見るとコストがかかるのは本体よりもむしろトナー、ドラム、紙等のいわゆるランニングコストになります。ちりも積もれば山となるランニングコストを計算するとプリンタ本体価格なんてたかがしれています。そこで価格比較する際はプリンタ本体はどうでもよく、むしろ数年間のランニングコストで比較してみましょう。

【次に重要なのは有償保守の内容と価格】
家庭用プリンタの感覚でいくと有償保守の重要性をあまり感じないのですが、業務用レーザープリンタの場合有償保守はとても重要です。有償保守に期待すべきはオンサイト修理と清掃です。毎日使う機械なので壊れたら電話一本ですぐに直しに来てくれることは重要です。またレーザープリンタはかなり汚れるので有償保守の中に定期清掃があることもとても重要です。これらを自分達の力でやろうとすると長い目で見たら逆に割高になることでしょう。

【そして印字速度】
大量に印刷することになると思うので印字速度が速ければ速いほどよいです。が、逆転の発想で、同じ費用をかけるのであればちょっと遅い機械を2台導入したほうが冗長化、印刷分散化といった観点でむしろよいかもしれません。

会社創業当時、パソコンや備品の購入はケチったものの、レーザープリンタだけは当時の会社規模からしたらかなり贅沢なものを導入しました。当時社長は「こんな大きいの必要？」と言っていましたが、今となってみればあのときの選択は正しかったようです。4年経った今でも現役で使われております。が、当時保守サービスに入らなかったのは大変失敗でした。修理代と清掃代だけでかなりの費用がかかっています。そんな反省から今日はこんな記事を書いてみました。

データセンター選びのポイント

現在利用しているデータセンターは3箇所目になるのですが、毎回データセンター選びにはとても苦労しました。そこでこれまでの経験を踏まえて、ここでは僕的なデータセンター選びのポイントを書いてみたいと思います。

【ポイント】
まずあなたがデータセンターに何を望むかはっきりさせることが重要です。僕が重要だと思うポイントとしては次のようなものがあります。

・データセンターの所在地
→言うまでもなく事務所から近いほうが有利です。ただし地震等自然災害に強いのは必須です。

・入館セキュリティーの厳しさ
→強ければ安心なのですが、頻繁に現地で作業するのであればむしろ入館セキュリティーは弱いほうが使いやすいです。(←かなり重要。以前使っていた某大企業系データセンターはセキュリティが厳しすぎて現地作業するのが億劫で・・・)

・ラックは持込みか、貸し出しか
→ラックマウントサーバの場合、ラックマウントキットとラックに相性があるので、もし備え付けのラックとラックマウントキットが合わないと棚板を使うこととなり、スペースがもったいないです。また備え付けのラックが空気循環が悪いタイプだとたくさんサーバを詰め込めないので、そういう場合はラック持込みがおすすめです。

・温度管理
→温度がSLAで決められているか。サーバはかなりの熱を排出するので温度管理は重要です。

・備品貸し出しの柔軟性
→工具、イス、机、キーボード、温度計、ＬＡＮケーブル、シリアルケーブル等現地作業ではいろいろ必要になりますが、そういったものを柔軟に貸してくれるところは大変使い勝手がよいです。（うちが使っているデータセンターは係の人と顔見知りなので何でも貸してくれてとても助かっています。以前使っていた某大企業系データセンターは何も貸してくれなかったからなぁ。。。）

・廃棄ゴミの処理方法
→廃棄ゴミ処理は意外と重要です。頻繁に発生するダンボール等のゴミが現地で処理できないとかなり大変なことになります。（以前サーバ100台箱出ししたことがありますが、2トントラック2台分のゴミが出ました。あのときはしんどかった・・・）

・重加重機器への対応
→ハイエンド機器になると数トンという重さになることがざらです。それに対応しているかどうか。

・様々な電源への対応
→100V,200V両電源に対応しているか。またハイエンド機器になると電源プラグが特殊な形状だったりすることがざらで、それに対応しているかどうか。

・搬入スペースや駐車場の有無
→これも意外と重要で、サーバ搬入時、搬入スペースや駐車場がないとかなり悲惨なことになります。特に数トンクラスの機器の場合はそれらがないと悲劇です。

・MSP(マネジメント・サービス・プロバイダ)サービスの有無
→トラブル発生時、電話をかければ電源on/offしてくれるリモートハンドサービス程度から、常時モニタリングしてくれていてトラブル発生時は勝手に操作マニュアルを見ながらコマンド操作してくれるところまで行ってくれるようなサービスが必要か。

・空きラックスペース量
→サイトの伸びが急激でラックやスペースの利用が急増しそうなのであれば、残ラックスペースは重要です。

・常駐スペースの有無
→社員がデータセンターに常駐する場合は常駐スペースを借りられることができるか。

・ケージの有無
→ケージ（柵ですね）を設置できるか。

・ネットワーク回線のコネクティビティー
→IX直結か、大手ISPとのトランジットを豊富に持っている業者であるとよいです(通信系の業者が運営しているデータセンターだと安心ですが、中小のデータセンターだとこのあたりが心配です)。もしくはキャリアフリーを謳っていて外部回線を引き込めるデータセンターもあります。

・UPSや発電機の有無
→停電時どの程度耐えられるのか。ここで注意なのはいくら発電機が完備されていたとしても災害で道路が封鎖されてしまったしたらガソリン等燃料を給油できないのでUPSがあることも重要です。

・火災発生時の消火方法が水かガスか
→水だと機械が死にます。ガスだと人が死にます。そんなわけで個人的には水がお勧めです(?!)。

・イレギュラーな要望に強い
→サイトが大きくなってくると様々な要望が生まれてきますが、それらのイレギュラーな要望に相談に応じてくれる親切なデータセンターがよいです。（今使っているところは大変助かってます）

・そして価格
→データセンターの価格はぴんからきりまでなので、「品質より価格」でいくのか「価格より品質」でいくのか決める必要があります。ただしかなりまとまったオーダーをすれば「品質と価格」の両立は可能ですがこればっかりは会社規模に拠りますね。（価格に関する一つの目安の数値があるのですが、さすがに公にはできません。興味がありましたら私に直接聞いてください）

【結論】
僕は最初、データセンターは極端な話し場所とネットワークさえ提供されるのであれば安ければ安いほどよいと思っていました。この考えはサーバを一度取り付けてしまえばあとはサーバ増加がほとんどないサイトの場合はたしかにその通りなのですが、頻繁にサーバ増強のために現地作業が必要なのだとしたら僕の最初の考えは間違いで、極力上記のポイントを押さえたデータセンター選びをするのがとても重要だと思いました。

【ストレージ】パフォーマンスを上げるキャッシュ容量の考え方

昨日に引き続きストレージのネタに行きたいと思います。今日はキャッシュ容量の考え方を書きます。

最近のハイエンドストレージのキャッシュは大容量です。代理店さんからストレージの提案をいただくと、最近では1GBなんて当たり前。4GBや8GBは割と普通で、まれに64GBなんて提案をいただいたこともあります（64GBっていったらハードディスク容量と変わんないよ～＾＾）。しかしストレージのキャッシュは非常に高価なので、今回は最適なキャッシュ容量の考え方を述べてみたいと思います。

【そもそもストレージのキャッシュって何？】
キャッシュする・・・貯蔵するということなのですが、IEのキャッシュやWEBキャッシュサーバと違ってストレージのキャッシュって何を貯蔵するのかちょっとわかりにくいです。ストレージにおけるキャッシュの役割はベンダーによっても違うようですが主に下記の3点に集約されるようです。

　①最近アクセスしたデータ（読み取りキャッシュ)
　②使用を見越してディスクから読み取られたデータ（先読みキャッシュ）
　③最近書き込まれたデータ（書き込みキャッシュ）

【キャッシュのヒット率と利用率について考える】
これを踏まえてキャッシュのヒット率と利用率について考えてみたいと思います。最適なキャッシュ容量を考える上で重要なのはリードの場合はキャッシュのヒット率、ライトの場合はキャッシュ利用率です。IEのキャッシュやWEBキャッシュサーバの場合はキャッシュ容量を大きくすればするほどキャッシュヒット率が向上していきますが、ストレージの場合は場合によります。ここではシーケンシャルリード、ランダムリード、シーケンシャルライト、ランダムライトの4パターンで考えて見ましょう。

■シーケンシャルリード
連続したデータをリードする場合です。この場合は先読みキャッシュ機能のおかげで高いキャッシュヒット率が期待できます。このアクセスが多い場合はキャッシュ容量を増やせるだけ増やすのがよいでしょう。

■ランダムリード
ランダムにデータをリードする場合です。この場合は上記キャッシュ機能①②③のいずれにもひっかからないので
このアクセスが多い場合はキャッシュヒット率を上げるためにキャッシュ容量を増やすことは得策ではありません。

■シーケンシャルライト
連続したデータをライトする場合です。この場合は書き込みキャッシュ機能のおかげで高いキャッシ利用率が期待できます。

■ランダムライト
ランダムにデータをライトする場合です。この場合も書き込みキャッシュ機能のおかげで高いキャッシ利用率が期待できます。

【考察】
ストレージキャッシュはランダムリードに弱いです。DBはランダムリードが多いと思われるのでDB用途にストレージを購入する場合はこの弱点回避のためにはキャッシュ容量を増やすこと以外の別の手段を取る必要があります。一番効果的なのは一番アクセスが多いデータだけに限ってキャッシュ上に全てのデータを置くことだとかいろいろ考えられますね。それは今回の趣旨と違うのでまたいつか別の機会にでも。

【ストレージ】パフォーマンスを上げるHDD構成の考え方

(2016/5/29追記: 記事執筆当時と違って現在はフラッシュストレージ、仮想ストレージ、様々なキャッシュ、安価なiSCSI等、技術が進歩しているので下記の内容は古くなってしまいました。)

ハイエンドストレージの導入を検討することになった場合悩みどころがたくさんあります。思いつくことを挙げるだけでもメーカー、モデル、ディスク実容量、ディスク本数、RAID構成、キャッシュ容量、ファイバーチャネル本数、FCスイッチポート数、パーティションのきり方とデータの載せ方等々いろいろあります。いずれこれら全てのポイントについてこのBLOGの中で触れてみたいと思うのですが、今回はその中でも特にディスク総容量とディスク本数の話題に触れてみたいと思います。(ちなみにディスクのインタフェースにはS-ATA、SCSI、FC(ファイバーチャネル)等いろいろありますがハイエンドストレージの場合はS-ATAやSCSIを選ぶことは考えにくいのでここではFCを前提で考えます)

【ディスク実容量の決め方】
例えば現在データが50GB、年内100GB、来年末に200GBになることが見込まれているとした場合、どれくらいのディスク実容量にするのが妥当だと思いますか？ ここで判断のために重要となるの今何が問題なのかです。すなわちディスク容量が足りないことが問題なのか、単にDASからNAS/SANへ移行することだけが目的なのか、もしくはパフォーマンスが遅いことが問題なのかということです。

ディスク容量が足りないことが問題な場合や、DASから単にNAS/SANへ移行することだけが目的な場合では、必要な分のディスク総容量を用意すればよいでしょう。それが200GBなのか300GBなのか500GBなのかはどこまで余裕を持たせるかということなので価格と予算を見て決めればよいでしょう。

それに対してパフォーマンスが遅いことが問題な場合。この場合はちょっとパラダイムシフトが必要です。パフォーマンスを上げるためにはディスク本数が多ければ多いほど良い。よってディスク総容量は大きければ大きいほど良いです。現在データが50GBなのだとしたら、例えば1TBとか10TBとか、それくらいディスク総容量を持つくらいの勢いで行くのがよいと思います。

【パフォーマンスを上げるためのディスク本数の決め方】
パフォーマンスを上げるための基本的な考え方を記します。

① HDD回転数が最大のものを選ぶ。（現在であれば15000rpm）
② HDD容量が極力小さいものを選ぶ。（が、製造中止の恐れのあるものは選ばない）
③ ①と②のものをたくさん並べてストライピングする。

ストライピングは偉大です。どんなにディスクI/Oが高いシステムであっても、基本的にストライピング本数を増やせば増やすほどディスクI/Oが分散されるのでレスポンスが上がっていきます。また現在HDD回転数が15krpmのものは18GB,36GB,72GBになると思いますが、18GBのHDDはそろそろ製造中止が予想されるので選ばないことが無難そうです。36GBもそろそろ危ないかもしれないです。そんなわけで、72GB(15krpm)か36GB(15kpm)のHDDを横にたくさん並べてストライピングするというのがよいと思います。(ただしストライピングとはいっても実際はRAID1+0構成を選択すべきなのは言うまでもありません)

同じ144GBでも下記の3パターンの中では(3)がパフォーマンス最速
　(1)144GB(10krpm): [HDD]
　(2) 72GB(15krpm): [HDD][HDD]
　(3) 36GB(15krpm): [HDD][HDD][HDD][HDD]

【ストライピング可能本数はシャーシによってまちまちである】
ただしストライピング可能本数が、ストレージ本体によってまちまちであることに要注意です。4本、8本、16本、もしくはまれに無制限というものもあります。これはメーカーによってもばらばらですし、同じメーカー内でもばらばらなことが多いです。カタログにこの制限が書いてないこともありますのでその場合は代理店さんに質問するのがよいでしょう。

ただしこの制限を回避する裏技もあります。それはソフトウェアRAIDを使うことです。ハードウェアRAIDによるストライピンググループをソフトウェアRAIDで束ねるという方法です。ソフトウェアRAIDを使うことは特にWindows Serverではとても不安がよぎりますが、安定性を謳うハイエンドUNIXサーバやメインフレームの世界では意外と現実的だったりします。

RAID0+1とRAID1+0の違い

RAID1+0とRAID0+1に違いってご存知ですか？特にハイエンドストレージを導入するときにはこの違いについての理解がとても大切になってきますのできちんと知っておいてください。

【RAID1+0とは？】
ミラーリングしたグループをストライピングしたのがRAID1+0になります。

[1 2]、[3 4]、[5 6]、[7 8]というミラーリンググループがあったとします。

[1] | [3] | [5] | [7]　　｝　ミラーリンググループを
[2] | [4] | [6] | [8]　　｝　束ねてストライピング

この構成時、例えばHDD[1]が死亡した場合、続いてHDD[2]が死ぬとRAID全体が死亡となりますが、それ以外のHDDが死んでもRAID全体としては生きつづけます。

[X] | [3] | [5] | [7] 
[2] | [4] | [X] | [8]

↑この状態でもそれぞれのミラーリンググループは生きているので大丈夫。

[X] | [3] | [5] | [7]
[X] | [4] | [6] | [8]

↑この状態だと１つのミラーリンググループが壊れ、ストライピングも壊れていまうためアウト！

【RAID0+1とは？】
ストライピンググループをミラーリングしたものがRAID0+1になります。

HDD[1]～[4]で構成されたストライピンググループ１とHDD[5]～[8]で構成されたストライピンググループ２があったとします。

[1 2 3 4] <- ストライピンググループ１
[5 6 7 8] <- ストライピンググループ２

この構成時、例えばストライピンググループ１のHDD[1]が死亡した場合はグループ１のストライピングが使えなくなります。よってこの状態ではストライピンググループ２だけが動いている状態になるわけですから、この時HDD[5][6][7][8]のいずれかのHDDが1本でも死亡したらRAID全体が死亡となります。

[X 2 3 4] <- ストライピンググループ１
[5 6 X 8] <- ストライピンググループ２

↑この状態になると両ストライピンググループが壊れるのでアウト！

【パフォーマンスの違い】
2009/10/7に「|さん」という方から下記のようなコメントをいただいております。ありがとうございます！

「RAID0+1とRAID1+0では、パフォーマンスが違います。

特に書き込みにおける処理の違いは明確です。これは、RAID1が、両ディスクのSyncが終わって初めて書き込み終了となる特性によるもので、RAID0+1では、書き込み終了はストライプセットのパフォーマンスが出せるのに対して、RAID1+0では、単体Diskのパフォーマンスしか出せません。

最近のRAIDコントローラーでは、ライトキャッシュを備えることで、Asyncミラーも許すようですが、安全性の観点を上げるのであれば、Syncミラーとなりますので、パフォーマンスに差が出てしまうのです。」

・・・補足させていただくと、OSからRAIDコントローラーに書き込み指示があったとき、実際にディスクに書き込まれた後に書き込み終了を返すのがSync(同期)なのに対して、とりあえず書き込むデータをRAIDコントローラーのバッファに置いた状態で書き込み終了を返し、後でゆっくりディスクに書き込むのがAsync(非同期)ですね。同期と非同期では相当なパフォーマンス差なので、一般的には非同期で使われることが多いと思います。

コメントいただいた中の「安全性の観点」というのは、キャッシュに乗っているデータがまだディスクに書き終わってない、いわゆるダーティなデータが残っている状態のときに、RAIDコントローラーへの給電が何らかの原因で途絶えることでディスクへの書き込みが正常に終わらないリスクのことを指しています。このリスクに対してハードウェア処理によってRAID1+0 や RAID0+1を扱える業務用RAIDコントローラーには通常キャッシュデータ保護のためのバッテリーが搭載されていて、キャッシュデータ消失リスクを軽減しています。

1000BASE-Tと1000BASE-SXではどちらが良い？

1000BASE-Tと1000BASE-SX、要するにUTPケーブルと光ファイバーケーブルではどちらが良いか、という話しをしてみます。ここでは1Gについて書いてますが10G(10GBASE-Tと10GBASE-SR）と置き換えても同様です。

さて、ギガビットネットワークを構築する際、昔だったら1000BASE-SXを選択するのが当然でした。しかし今は1000BASE-Tがよく使われるようになってきて、1000BASE-Tと1000BASE-SXのいずれも選べるのであればどちらが良いか迷う方も多いのではないでしょうか。IAサーバであれば1000BASE-Tでいいかとなっても、高価なエンタープライズサーバの場合はどうでしょう。
 

【選び方の例】

長距離引き回すのであれば1000BASE-SXか、もしくは1000BASE-LXでなければなりません。が、数メートルくらいの距離なのであれば断然1000BASE-Tを選ぶべきです。理由は

・1000BASE-SXはネットワーク機器が高い (が、最近はそうでもないのかな？)
・1000BASE-SXはトランシーバー(SPF/GBIC)が高い
・1000BASE-SXは光ケーブルが高い
・1000BASE-SXは光ケーブルが折れやすく、取り扱いが不便

このようなことを考えると1000BASE-SXを積極的に選ぶ理由が見当たりません。「1000BASE-Tはノイズが乗りやすいのでは？」などと感覚的に思ってしまうところですが、そもそも1Gbps近くに達するような超高負荷な状態ではノイズ云々で悩んでいる場合でなく、緊急で機器増設が必要となる状況かと思います。

HTTP圧縮はネットワーク帯域削減に効果的

規模が大きくなるにつれて当たり前なことですがネットワークトラフィック使用量がどんどん増えます。ネットワーク部分の費用って結構高いのでこのコストを減らすことはビジネスの上でとても大切です。

そこで最近果たして我々はネットワーク帯域を効率的に使っているのかという観点で考えました。そしてあることに気づきました。それはHTMLファイルのようなテキストファイルは無駄にスペースやタブがたくさん含まれていたりするので圧縮すればその分ネットワーク帯域を節約できるはずだ、ということです。この件についてちょっと調べて見ると、なんとWEBサーバ自体にHTTP圧縮という機能がついているではありませんか。

ということで早速試してみたのが以下の内容です。ものすごい効果です。

ちょっとした設定変更でネットワーク費用が削減できるなんてすばらしいですよね。是非お試しください。

■参考
・HTTP圧縮を使用するだけで帯域幅もコストも削減できる～米調査結果(2003/7 InternetWatch)
・IIS 5.0 Web サイトで HTTP 圧縮を使用する
・Apacheにmod_gzipを組み込んで帯域を節約したい