ただつらつらと日記が書かれていくようです。

カテゴリー: ITめいたこと (16ページ目 (31ページ中))

Bay Networksのハブが発見された。

古いスイッチングハブを整理してたら…唐突に発見されたのが、この「高温注意」とか書いてあるハブ。しかも、「Dual Speed Hub」って書いてあるあたりからして、これ、リピータハブだ。

baynetworks

ぱっと見た感じは、本体の塗装の色合いからして、ネットギア製の使い古されたハブって感じであって、実際に「NETGEAR」と大きく書いてあるものの、よーく見てみると、左下に「Bay Networks」と書いてある。

で、例の如く、Wikipediaあたりで調べてみると、

  • 1994年にカリフォルニアのサンタクララで創業
  • 対シスコシステムズのために、イーサネット製品に強みを持っていたSynOpticsって会社と、ルーターに強みを持っていたWellfleetを合併してできた会社
  • どうやら、SynOpticsがサンフランシスコが拠点で、Wellfleetって会社がボストンが拠点で、どちらの街も「湾」(サンフランシスコ湾とボストン湾)で有名だから、bay networksなのだとか
  • Bay Networks自体は1998年にNortelに買収されるものの、中小企業向けの製品群はNetgearのものとなったらしい(…ってことは、Nortelは欲しいものだけ持って行ったって感じか)

NETGEARと、Bay Networksの両方のブランドが書いてあるってコトは、このリピータハブは、1998年以降、Bay Networksの製品群がNETGEARに吸収されていく過渡期に作られたものってことだろう。すると、かるく10年以上前の製品って可能性がある。

まぁ、博物館に飾っておくシロモノでもなさそうだし、これといって使い道もないし(ACアダプタはあるけれど、今のところ、使えるかどうかよくわかんないし)破棄してしまおうかと(汗)

DELLの”CERC SATA 1.5 6ch”とHDD故障(後編)

前回のエントリーで、DELLのPowerEdge1800のHDDがコケて、RAID Arrayの冗長性が失われたのでHDDを交換したところまでは書いた。

ふと、RAID Arrayの状態を確認すると、「Degraded」であって欲しいのに、「Failed」担っていることに気がついた…え。なんで?HDD交換しただけなのに?そういえば、勢い良く警告が鳴ってたので、慌ててHDDを交換したから、故障したHDDを取り出す前にdetachみたいなことをやってなかったかもしれないが…いきなりArray自体がFailedになるものなんだろうか。なんか終わった気がする(遠い目)

で、よーく見ると、謎の設定を見てみると、RAIDカードの管理画面で、FailしたArrayを選択した時に「CTRL」+「R」で「RAIDのEnable/Restore」ができるらしい。で、現実逃避のためにOSを起動してみたが、該当のArrayがOSから見えない。同じRAIDカードに刺さっている他のドライブは見えているので、FailedになったArrayはRAIDカードが隠蔽しているんだろうなぁ。

仕方ないので、RAIDカードの管理画面に戻って、「RAIDのEnable/Restore」を選択したら、とりあえず、「全部データが飛ぶかもよ」と脅されるが、もはや選択肢は無いので実行。そしたら、RAIDが「failed」から「degraded」状態になった。

んで、ホットスペアにしておいたディスクがArrayに組み込まれて、Rebuildが始まった!…が、この”CERC SATA 1.5 6ch”って信じられないくらいにHDDへのアクセスが遅い。たかだか1TBもないArrayのRebuildに丸1日は確実に必要なスピードで、さっぱり進捗しない(Arrayのrebuildが遅いRAIDカードが、普段のIOは速いなんてことはなさそうな気がするから、こんなRAIDカードを売ってて、DELLは大丈夫だったんだろうか)

ま、いろんなリスクはあるけれど、サーバの停止で業務を止めるわけにもいかないので、とりあえずOSをブートして、フルバックアップを取った上で復帰させることにした。ま、冗長性が失われているので、もう1本のHDDが飛んだら改めて終わるけれど(汗)、せめてバックアップ取ってあるしな、ということで。止めておいても怒られるだろうし、無理やり動かしでデータが飛んでも怒られるわけで、それなら後者はデータが飛ばずに済めば怒られないわけだし。

その後、Arrayのrebuildが続くものの、数時間後にOSがなぜかスタックしてしまう。スタックさせとくわけにもいかないから、サーバを強制的に再起動、それに伴って、RAIDのRebuildもやり直すはめになるのだが、その頃はなんにも気づいてもいなかった…。

古いサーバのおもりは、とにもかくにも疲れるので、可能な限り、買った時点から運用時間を決めて予防的にハードウェアを交換しておくのがいいのかもしれないぁ…。なんせ急に対応しなきゃいけなくなるときのコスト感はかなりハンパないからなぁ。。。

しかし、RAID Arrayのrebuildは終わるんだろうか…。

DELLの”CERC SATA 1.5 6ch”とHDD故障(前編)

てか、古いサーバをいつまで使うんだ…と思いつつも、DELLのPowerEdge 1800ってサーバを今でも使っていて、それに刺さっているHDDがコケたらしい。とりあえず、甲高く、不快な音が大きめに響きわたった。

PowerEdge1800には、DELL純正のCERC SATA 1.5 6chってRAIDカードを使っていて、RAID1が構成してあるのでHDD1台の障害には対応できるはずだ、ということで、いそいそとHDD交換の準備を始めた。そういえば、このDELLのRAIDカード、いかにも純正っぽい型番だけど、POST時の画面出力からすると、Adaptec製のものであることがわかる。で、どうやら、AdaptecのOEMでAAR-2610SAって型番らしい。

IT機器なんて、OEMできないものがないくらいの世界ではあるから、どこのメーカーもこんなもんだろう。そういえば、某メーカーがUNIXサーバをOEMで売ってて、OEM元のダンボールのメーカー名の上に自社のロゴを貼っただけで出荷(付属するマニュアルとかには、OEM元のロゴしかない)してたのも見てたから、こんなのは生やさしい部類か。

…と、そんなことを思いながら作業は継続。

まずは警告音を止めなきゃいけないんだけど、Windows上で動くDELL製のサーバ管理ツールで止められると確信していただけれど、なかなか設定画面が見つからない(汗)四苦八苦して見つけたけど…わかりづらい。後から判明するんだけど、RAIDカードの管理画面に入れば、RAIDカード自体の設定の欄に、Alert Managementみたいな項目があって、そこで設定できるようだ。

ま、RAIDカードはホットスワップに対応してそうだけど、サーバが対応してないので、仕方なくシャットダウンする。で、ネジをいくつか外して、HDDを引っ張り出したんだけど、SATAケーブル、電源ケーブルを全部外さなきゃいけなさそう…てか、筐体、こんなにでかいんだから、HDDトレイでホットスワップさせてくれ…という面倒くささ。

その後、HDD交換も終わり、ブートしてRAIDの管理画面から新しいHDDをホットスペアにしてみる(…というか、RAID Arrayに突っ込む方法がよくわかんなくて、これくらいしか方法が思いつかなかった。マニュアル読みたかったがDELLのサイトは…(遠い目))

ところが、RAID ArrayのRebuidは始まらない…。

後編に続く。

さくらインターネットのレンタルサーバのディスク増量

そういえば、さくらインターネットからメールが来ていて、今度、借りているレンタルサーバのディスクの容量が増えるらしい…が、よーく見ると、OSバージョンパップとも書いてある。

OS : FreeBSD 7.1 32bit → FreeBSD 9.1 64bit

…OSのバージョンが激しく上がるなぁ…とは思ったものの、OSを64bitするあたりからして、サーバのハードウェアをリプレース(つまり、新サーバは4GB以上のメモリを搭載)するんじゃないかって気がするんだけど、どうなんだろう。90分くらいあれば、旧サーバからHDDを取り外して新サーバに繋げばデータを吸い出せそうな気がするし。いや、RAID組んでるとそう簡単にもいかないから、例えば、NFSで繋ぐなんていう選択肢を採るんだろうけど。

仮に、もし、仮にこの度のディスク増量とOSアップデートが実態としてサーバのハードウェアのリプレースだとすると、メモリの増量やCPUの増強といったスペックアップも兼ねるから個人的にはありがたい。ちょっと楽しみな気がする…が、先日、勢い余ってレンタルサーバを契約し直してしまったんだけどなぁ(遠い目)

果たして実態はどうなるんだろう。

Amazon Cloud Driveが直らない…

先日、「Amazon Cloud Driveがなんだか切ない。」って記事を書いたのが、6月。それも、6月のアタマ。んで、今が9月中旬。

なんとなく3ヶ月くらい経過したモノの、私のPCで動いているAmazon Cloud Driveのデスクトップアプリ(Windows版)は、ローカルに.lockってロックファイルだけ作って、同期終了してしまう、と。この問題はAmazonのBTSみたいなものに載ってはいるらしく、思い出したようなタイミングでサポートからメールがやってくる。「担当部署で調査中」「問題が修正されるまでもちっと待ってくれ」みたいな趣旨のテンプレを貼り付けたメールが届く。AWSのサービスのリリースのスピード感を前提にすれば、恐ろしく時間がかかっているようにも見えるので、優先度が低い問題ってことなんだろう。

Amazon.comと、Amazon.co.jpでアカウントが別管理になってたのに、Kindleを日本でもリリースするくらいのタイミングで、なんとか2つのアカウントを連携させようとしたのか、統合しようとしたあたりが、やっぱりイケてなかったんだろうなぁ。

これ、日経コンピュータの「動かないコンピュータ」に載るくらいアレなことだと思うんだけど、とはいえ、Amazon.comに取材は不可能か(笑)

iPhoneの充電が完了したら速やかにケーブルを外すべきか。

こんな記事を見つけた。

iPhoneの充電率が100%を超えたあとも電流は流れている? – いまさら聞けないiPhone

iPhone 5の電源をオフにして30分経過したたあとも0.2A前後の電流を測定できたので、電気的に接続された状態にあることは確かです。やはり、満充電後はすみやかにケーブルを外したほうが、バッテリーの早期劣化防止にはプラスだといえます。

ふむ、どうやら「充電完了後にiPhoneに電力が流れている」から、充電完了後に、すみやかにケーブルを抜いた方が「バッテリーの早期劣化防止」につながるらしい。

例えば、AppleのWebサイトにはこんなことが書いてある。

リチウムイオンバッテリー

大部分のリチウムイオンポリマーバッテリーの充電は、デバイスのバッテリー容量の80%まで高速充電した後、トリクル充電に切り替わります。

どうやら、80%以降は「トリクル充電」になっているらしい。

「トリクル充電」についてWikipediaには、こんな記載がある。

トリクル充電

トリクル充電(とりくるじゅうでん) は二次電池の自然放電を補うために、絶えず微小電流により充電する方法である。

いかなる状態であろうが、二次電池に充電することが電池の劣化に繋がるというのは確かだろうけどなぁ…。さくっと抜いて実際に使うまでに自然放電、ないし、スリープ時の消費電力でバッテリーの残容量が減るわけだから、それを考慮するとトリクル充電させてバッテリーの残容量を維持しといた方がいいような気がしないでもない。要するに、バッテリーの劣化を気にしてさっさと抜いて置いておいて、いざ使うって時に残容量が減ってたら、それはそれで切ないのではないか、と。

ただし、(Androidだとそうもいかないような気がするものの)iPhoneはスリープ時にほとんど電力を消費しない、自然放電も充分に少ないというのなら、それはそうなんだろうけど。

SSDを使ってみたものの…

たまたま職場でノートPCが1台余っていたのでHDDを外してSSD(TOSHIBAの「THNSNH128GCST」)に換装した。CentOS6をインストールしてディスクI/Oが頻繁に発生するような重いバッチ処理を回してみれば速く処理が終わるに違いない!と意気込んでもろもろのインストールと初期設定をやってみた。

んで、CentOSのインストールが終わって、hdparmで読み込みのスループットを測ってみた。

/dev/sda:
Timing cached reads: 6524 MB in 2.00 seconds = 3265.55 MB/sec
Timing buffered disk reads: 946 MB in 3.00 seconds = 315.03 MB/sec

従来通りのHDDを積んだ開発マシンで測ってみたら、こんな感じだったので、やっぱり速い。

/dev/sda:
Timing cached reads: 4656 MB in 2.00 seconds = 2328.52 MB/sec
Timing buffered disk reads: 276 MB in 3.01 seconds = 91.61 MB/sec

簡単なベンチマークではあるけれど、結果は上々ということで、重いバッチを走らせてみたら、思ったよりも速くない。で、topを見ていて気づいたのは、OSはSSDとしては読み書きで待っていないようで、結局はCPUがボトルネックになってしまっているようだった。確かに、今回使ったノートPCはThinkPad X121eなので、CPU「Core i3-2367M」。廉価なノートPC向けのCore i3だからなぁ…(遠い目)

SSDに換装することで、ディスクのI/Oは速くなったけれど、結局は、ディスクがボトルネックだった状況から、CPUがボトルネックな状況に移行しただけの話か。SSDに換装するだけでは、システム全体としての劇的な性能向上までは見込めないという、当たり前の話(多少は速くなったとは思うけど)だったようだ。まぁ、SSDを使うことで、速いCPUを活かせるようになったという理解ができるのも確かなんだけど。

MariaDBとMySQL-libs。

今更ながら、MySQL互換のMariaDBを使ってみようと思いついた。サーバのOSはCentOS6.4のx86_64版。

で、MariaDBのサイトでyum向けのレポジトリの設定が取得できるので、ささっと設定ファイルを/etc/yum.repo.d/に置いてみた。

ただ、MariaDBを入れる前にMySQL関連のRPMを削除しようと思ったら、「mysql-libs」がやっかいな依存関係を持っていた。例えば、crontabsとかPostfixと依存関係があって、MySQL-libsをアンインストールしようとすると、crontabsとかpostfixも一緒に削除されてしまうようだった。なんか重要なモジュールとの依存関係って微妙だなぁと思っていたところ、試しにyumから「MariaDB-compat」を入れてみたら、MariaDBのモジュールでmysql-libsがリプレースされることがわかった。

これによって、PostfixなどのMySQL-libsに依存関係を持ったアプリケーションを維持しつつ、MariaDBを導入することができそうだ。さすがにこの辺の依存関係の解決が難しいようなら、しばらくMySQLを使っていようかという気になりそうで、(いつ頃に解決されたのかよくわからないけれど)yumレポジトリで依存関係を解決できたら楽だな、確かに。

カゴヤ・クラウド/VPSの「最大メモリー容量」って何だ。

さくらのVPSからの…

さて、そろそろ、さくらのVPS*1からどっかにお引っ越ししようかなぁと思って、VPSサービスを物色していたら、たまたま見つけたのがカゴヤジャパンのVPSサービス。

メモリーの表記の仕方

ざっと、カゴヤジャパンのVPSのサービスサイトを眺めてみたら、どうやらOpenVZを使った仮想化を使っているらしく。VPSの基盤にはKVMとかOpenVZが使われるが、どうせたいしたことをやるわけじゃないので、仮想化の基盤によってどうにかなるようなことは想定しづらい。ま、どっちでもいいだろう。

ただまぁ、結局のところ、この手のVPSのサービスは、メインメモリとHDDのサイズといったスペックと、その価格で比較するわけだが、カゴヤジャパンのVPSのメモリの表記の仕方がなんかちょっと気になった。

例えば、このページに書いてある「タイプA」のメモリに関する表記は以下のような感じだ。

保証メモリ 1GB

最大メモリー容量 2GB

「保証メモリー」と「最大メモリー容量」の意味がなんとなくわからない。いろんなVPSサービスを比較してみての感覚にすぎないが、月額870円くらいだとするとメインメモリは1GBがせいぜいだろう。だから、「保証メモリー」ってのは実際に、VPS上のOSから見えるメインメモリの容量で、それに、スワップを加えて「最大メモリー容量」と表記してる感じではないだろうか*2

確かに、スワップが使えないVPSサービスもあって、そういうサービスでメモリを使いすぎると、LinuxにおっけるOOM Killerがプロセスをなぎ倒していくみたいな惨事が起こるわけで、そういう意味ではSwapを利用可能にしているのであれば、その領域もメモリーとして書いちゃうことは嘘じゃないとは思うんだけど、なんかちょっとわかりにくい表記だなぁ、と。わかりやすいところに、最大メモリー容量ってのは…って説明を書いておいてもらえたらありがたいのだが…。

うーむ、さて引っ越し先のVPS、どうしよう。

*1:さくらインターネットがVPSを始めた辺りから使ってるので…そろそろ新しいハードウェアにお引っ越ししようかと

*2:一応、カゴヤジャパンのVPSのウリの1つにスワップが使えるってことって書いてあるし

WordPressに対するブルートフォース攻撃とか。

WordPressへの攻撃と、その防御

最近、WordPressへのブルートフォース攻撃が流行しているらしい。ま、WordPressが動いていれば、管理画面のURLはわかるわけだし、ブルートフォース攻撃はやりやすいだろうなぁ。しかも、デフォルトで「admin」アカウントが作成されるわけで、何にも考えていなければ「admin」ユーザーに対してパスワードを辞書式に当たればというわけで、クラッカーのみなさまに目を付けられやすいような気は確かにする。

ま、そのまま、攻撃を受け続けるというのも気持ちが悪いので、試しに「Login LockDown」というプラグインを入れてみることにした。このプラグインは、ログイン失敗の履歴を保存しておいて、一定期間における試行回数を超えたら、ブルートフォース攻撃(要するに、同じIPアドレスから何回もログイン試行する)と見なして、ログインを受け付けなくするらしい。

意外と…攻撃来てた

とりあえず、プラグインを入れてほったらかしにしていたら、ログインに失敗したアクセスを記録するテーブルにわらわらとレコードが出来ていた。たいしたPVがないブログに入れてみたけれど、2週間くらいの期間の間に、ログインに失敗した記録が500レコードほど出来ていた。思ったより多いなぁ…。うーむ。

もちろん、絶対にヤラれない自信がある人はともかくとしても、世の中の注目度とは裏腹に普通にWordPressのブルートフォース対策のためのプラグインとか入れておいた方がいいのかもしれない。もちろん、ブルートフォースを受けている間は、無駄にサーバのリソースが使われるわけで、それを防ぐということも多少意味があるかもしれないし。

«過去の 投稿 新しい 投稿 »