タグ: Windows Server 2008 R2

3 月の燃費とサーバの HDD を換装した話

大和 環Leave a comment

今月の遠出は月末に行った草津温泉なわけだが、この時の給油は 3 月には反映できなかった（草津で給油したものの、あまりにも値段が高かったので 30L だけ給油して 4 月になってしまったため）。その代わり先月の終わり頃に行った越後湯沢～水上旅行の分が積み残しになっている。この分が 2/25 の給油であり（高速で給油したため満タンにしなかった）、3/02 はそれを含めた燃費になっているわけだが、都内での走行が含まれているため、燃費的には 10km/L を越えなかった（汗）。

車種：トヨタ エスティマ アエラス 3.5L 2WD（Estima GSR50W）
Date 走行距離(km) 給油量(L) 単価(\) 燃費(km/L) メーカー 給油地
2/25 885.4 33.33 150 9.972 IDEMITSU 東京都江戸川区北小岩
3/02 57.09 143 Shell 東京都武蔵野市八幡町
3/12 462.8 57.22 148 8.088 ESSO 東京都杉並区井草
3/25 442.0 56.50 145 7.823 ENEOS 東京都西東京市中町
まとめ 1790.2 204.14 146.5 8.769 —- —-

ガソリンの値段はなんとも安定していない。143 円のものは最初消費税が入ってないのではないかとレシートを見直して計算し直したが、ちゃんと税込みだった。とにかく値下がって欲しいのではあるが……。

さて、amatsukami.jp サーバのシステム ドライブを SSD に換装してみた。草津から帰ってきてからの作業である（笑）。手順としては以下の通り。

  1. サーバのシステム ドライブをまるごとバックアップ
  2. サーバを止めて、システム ドライブの HDD を取り外し、新しい SSD をセット
  3. バックアップを SSD に書き戻す

作業はとくにトラブルなく、すんなりと進んだ。色々と速くはなったのだが、起動時間は特に変わらなかった（汗）。サーバの起動時間はストレージの速度ではなく、メモリ配置と各種サービスの準備に多く取られているようだった。また、ウェブサイトのデータは元から HDD 上にあること、MySQL のデータベースは SSD 上にあることからサイトの表示は体感するほど速くはなっていないと思われる。
が、まぁとりあえずシステム ドライブが 7 年近く稼働し続けていたので、交換出来てよかった。
新サーバに変えるまでのつなぎの処理である。

▼関連記事

8 月の燃費と msn.bot の多さ 厳しい iOS と疲れる電車通勤、そして 9 月の燃費 Default Thumbnail増設成功 glace.me と galette.me を amatsukami.jp で引き受ける

リバースプロキシの秘密は preserveHostHeader にあり

大和 環Leave a comment

ボクは aipo というグループウェアを一人で使っているのだが（笑）、一人で使うので、割と URL がテキトーだった。例に挙げれば、https://amatsukam.jp:3333/ って感じ。なんだよこの 3333 って数字は！ みたいなｗ
https は本来 443 で動くのだが（なので何も指定しないと 443 番で通信しようとする）、そちらは色んな人がアクセスするための別のサービスが動いているため、ボクしか使わないグループウェアの方はテキトーなポート番号を割り当てていたのだ。

が、先日、リバース プロキシというものを知ったボクはこの aipo も https://amatsukami.jp/aipo/ にできるのではないかといろいろ悪戦苦闘していた。

それがついに解決して、3333 を付けなくてもアクセスできるようになった。
Microsoft 製リバースプロキシである Application Request Routing の preserveHostHeader という設定を True にすることにより、インターネット網からアクセスしてきたホスト名でリバースプロキシ下にあるサーバ群にアクセスするようになった。
というわけでホスト名に関しては、まずは解決。

しかし問題はこれだけではない。aipo はルートディレクトリに配されている。どういうことかというと、https://amatsukami.jp:3333/ が aipo のホームページ（ホームディレクトリ）である。しかしこれを、https://amatsukam.jp/aipo/ にしたい。リバースプロキシだけでは、コレを解決できない（たぶん）。aipo 本体も https://amatsukami.jp:3333/aipo/ にしなければならないわけである。

んでなんとなーく aipo のドキュメントを眺めていると、昔 aipo ディレクトリで運用されていた名残があるような感じで、んじゃー、aipo フォルダってのを作ったら動くんじゃないかと思ってやってみたら動いたｗｗｗｗ
具体的には、aipo のインストール先である「dpl8110\tomcat\webapps」っていうディレクトリに、ROOT というディレクトリがあるので、それをそっくりそのまま aipo というディレクトリ名に変えるだけである（万全を期すなら、ROOT は残しておき、ROOT ディレクトリを aipo というディレクトリ名でコピーする）。こうすることによって、aipo は https://amatsukami.jp:3333/aipo/ で動くようになった。
次に aipo のプラグインなどを提供している container ディレクトリだが、こいつは単純にリバースプロキシで、https://amatsukami.jp/container/ ってアクセスが来たら、aipo のサーバにそのまま飛ばすようにすればよい。ただコレの欠点は、amatsukam.jp では container というディレクトリが使えなくなることだが、別に問題はないだろう（理想を言えば、aipo/container/ にするべき）。

また、3333 という数字をつけなくてすむようになったので、iPhone のカレンダーに aipo のカレンダーが取り込めるようになった。aipo に入力した予定表がそのまま iPhone でも見られる。イイ感じ！

下の写真はお昼に食べに行った「アカス」のランチ。タンドリーチキン付き。真ん中のはタンドリーチキンだよ！ 見間違えないでよ！（何

▼関連記事

リバースプロキシって便利！ LAN には LAN のお名前を… ジェンダーフリーとかフェミニストとかの価値観？ 満北亭

リバースプロキシの基本がわかってない（ぁ

大和 環Leave a comment

さて、昨日は古い PHP で動く旧コンテンツを、リバースプロキシ（Application Request Routing）を使って別のサーバに追い出すことに成功した。ということはだ、今別サーバで色々動いているものが、少なくとも見た目上は一つに集約できるのではないかということに気づく。

今、Redmine（プロジェクト管理）やグループウェア（Aipo）なんかが動いてはいるんだけど、それらは全部 HTTP でやりとりするのね。しかも Windows で動かすと全部独立したサービスで動くため、これらを一つの HTTP で動かすわけにはいかないという状況だ。

そこでどうしているかというと、不特定多数の人がアクセスするサービスはデフォルトに割り当て、ボク一人で使っている Redmine やグループウェアは TCP ポート番号を分けることによって使い分けていた。
たとえば、https://amatsukami.jp:9999/ なんて感じだ。でもこれはデフォルトの動作じゃないし、見た目もよろしくない。

リバースプロキシを使えば、https://amatsukami.jp/redmine/ ってやると https://amatsukami.jp:9999/ にアクセスするように設定できる。こうすることによって、全て https://amatsukami.jp/ で完結できる。

というわけでさっそく一番使用頻度が高いグループウェアで設定してみようとするんだが、これがうまくいかない。ホスト名が一致しないのだ。
どういうことかというと、リバースプロキシ経由になるということは、グループウェアにアクセスしに来るのはリバースプロキシと言うことになる（アクセス経路は以下の通り）。

ユーザ → リバースプロキシ → グループウェア

リバースプロキシとグループウェアは LAN 内で結ばれていて、お互い LAN 内の名前（ホスト名という）で呼び合っている。この LAN 内のホスト名はインターネットの世界では通用しない。でもグループウェアは呼ばれたホスト名で応答するように作られており、リバースプロキシは LAN 内でしか有効でないホスト名をそのままユーザに返してしまうため、インターネット網にいるユーザは結局アクセス出来ないのだ。

じゃぁ旧コンテンツはどうしているのかというと、旧コンテンツのエンジンである Pukiwiki Plus ! は返すホスト名を固定できるのだ。このホスト名をインターネットで通じる名前にしておけば問題ないというわけである。
ところがボクが使っているグループウェアにはこの機能が無い。
ただこの時、ボクはグループウェアの方に着目してしまったのよね……これが遠回りの原因になってしまった。グループウェアはオープンソースなもんだから、ソースとかを見始めちゃったのよね……orz
結局、この日は解決することができなかった。
（正解はリバースプロキシ側に、ユーザがアクセスしてきた時のホスト名のままでアクセスするという設定があるのだった）

下の写真は浅草橋で一番美味しい（とボクが思い込んでいる）、ろく月の豚白湯麺とチャーシュー丼。うまいー！

▼関連記事

リバースプロキシって便利！ たぐり庵 glace.me と galette.me を amatsukami.jp で引き受ける リバースプロキシの秘密は preserveHostHeader にあり

リバースプロキシって便利！

大和 環Leave a comment

TAMA Networks の旧コンテンツは Pukiwiki Plus ! というシステムで動いている。コイツは PHP 5.2 じゃないと動かない。5.3 以降では動かないのだ（どうも動くらしいのだが、IIS ではセキュリティ関連の機能がまったく働かない）。そのおかげで、amatsukami.jp サーバはずっと PHP を更新できないでいる。そうこうしているうちに PHP は 7 になってしまった。

一方、現在の TAMA Networks は WordPress というシステムで動いていて、これは現役のシステムであり、バージョンアップもされている。
そしていつかは WordPress が PHP5.2 では動かなくなるはずだ。現に WordPress のプラグインなどは 5.2 で動かないものもチラホラ出始めている。
しかし、先の Pukiwiki Plus ! のおかげで、こちらは PHP のバージョンを上げられない。
何かいい方法はないものか？ と、色々考えたあげく、二つの方法を思いついた。

  1. amatsukami.jp サーバで複数のバージョンの PHP が動くようにする
  2. リバースプロキシを使って、Pukiwiki Plus ! を amatsukami.jp サーバから追い出す

と言うわけで①を試そうとしたんだが、IIS7.5 ではこれがどうもうまくいかない。
いや、7.5 でもできると思うんだけどなぁ……。結果的に旧コンテンツが動かなくなるｗ
そこでやる気を失って放置してたら、ウェブサーバが落ちたｗｗｗ
どうやら旧コンテンツの実行にものすごく時間がかかるようになってしまったためで、旧コンテンツそのものにアクセス出来ないようにしたら、復活した。

これが 9/11 頃である。

その後も①に色々挑戦するも、何故かうまく動かない。まぁ amatsukami.jp サーバは 6 年も稼働し続けているし、その間、いろんな設定ミスだのなんだのをしてきたから内部がけっこうヤバいことになっているのかもしれない。
さっさと新しいサーバに移行しなければ……という結論には達するものの、技術的な勉強も兼ねて仮想サーバ（こちらは IIS8.0）に PHP を 2 バージョン（5.2 と 7）をセットアップした。するとすんなり両バージョンで PHP が動くではないか。なのでこの設定をそっくりそのまま amatsukami.jp サーバに持ってくると……やっぱり動かないorz
う～む、やはり amatsukami.jp サーバが怪しいんだなぁ……（実は PHP の設定が不味かった）。

そこで amatsukami.jp サーバにリバースプロキシを設定する。そして https://amatsukami.jp/scripts/pukiwiki/ 及び https://amatsukami.jp/pukiwiki/ にアクセスしに来たら、それは仮想サーバの Pukiwiki を呼び出すように設定した。
と言うわけで上のメニューにある「今は昔」のリンク先は amatsukami.jp サーバではなく、仮想サーバで動いているコンテンツだったりする。

将来的にサーバを新調したら、どっちの方法でやるかは悩むな。サーバを新しくしたら当然そっちでは複数のバージョンの PHP が動かせるはずだ。となれば別にリバース プロキシに頼らなくてもよい。
ただ将来的な設計で、ロードバランサなどを置く場合は、そもそも全てのサイトがリバース プロキシでの運用になるだろうし……。まぁそれはその時になったら考えよう。

下の写真はシャンブラとボクが勝手に呼んでいる『上海ブラッセリー』の塩やきそばと半チャーハン。ここのチャーハンは紅生姜が入っているのが特徴だ。半チャーハンの写真がフタルあるのは、ここ、半チャーハンはお代わり自由だったんだけど、それがなくなり、「普通」「大盛り」「特盛り」が選べるようになった。その大盛りと特盛りの比較写真が、チャーハンが二つ並んでる写真だｗ
あくまでも半チャーハンの大盛りと特盛りなので、大盛りが普通のチャーハンくらいの量だと思ってもらえれば間違いないと思われる。ただし、残っているチャーハンの量に影響されるのか解らないが、けっこう日によって量は違ったりするｗ

▼関連記事

たぐり庵 リバースプロキシの秘密は preserveHostHeader にあり PHP の恥ずかしい話と TV で見た分福 PHP が動かない

サーバのブルースクリーン問題、解決する

大和 環Leave a comment

10/7 にブルースクリーンで飛んだサーバだが、 10/16 にまた飛んだ。
で、そのエラー画面を見て原因はメモリだと確信を得たので、上位アドレスのメモリ 2 枚を抜いて運用してみた。amatsukami.jp サーバは DDR3 の 4GB が 4 枚ささっていて、合計 16GB。2 枚抜くと 8GB になってしまう。

amatsukami.jp サーバは仮想サーバが 4 台も動いており、常時 9GB ～ 12GB 使っている。
となると当然、8GB ではメモリ不足なわけで……。案の定、重すぎて話にならんレベルに……orz
しかし会社にも行かなくちゃいけないし、そもそも予備のメモリは会社だ。
とりあえず会社に行く。

ところで何故上位アドレスと推測したか？ それは、ブルースクリーンに陥るまでの時間が長いからである。常時使われている、より下位のアドレスならばもっと頻発するだろうと推理した。数日稼働し続けられると言うことは、①滅多に使われない領域、②壊れている箇所は常に異常というわけではなく、正常に動くこともある、という二つの仮説を立てた。
なので、上位アドレスのメモリを抜いてみたわけである。

それから日付の変わる頃に会社から戻ってきて、メモリを増設した。とはいえ会社で余っていたメモリは DDR3 の 2GB が 2 枚。なので搭載メモリは 12GB で運用ギリギリ(^^;

買い換えるまではこれでなんとか持たせたいところ。今更 DDR3 を買いたくないし（今は DDR4 の時代なのだ）。

ちなみにページ ファイルを SSD のドライブに作るようにしたら、だいぶ速くなった。

1610161889

▼関連記事

目が覚めたらブルースクリーンだったでござる amatsukami.jp サーバー、死す？ たぐり庵 LAN には LAN のお名前を…

amatsukami.jp サーバー、死す？

大和 環Leave a comment

amatsukami.jp サーバがブルースクリーンを出して、落ちた（爆）。
うひぃ。
今は代替機がないので、コイツに死なれるといろいろと困る。
ただまぁ、今年中にリプレースはしたいとおもってるんだけどねぇ。Windows Server 2016 にしたいし（今は Windows Server 2008 R2 で運用中）。

で、エラーの内容見ても、これがまたこう原因が複数あるタイプのヤツなのよね……。
とりあえずこのサーバは 6 回の夏をエアコンなしで過ごしてきたので、いろいろダメになっているんだろうなぁというのは何となく解る。一番疑わしいのはマザーボードとメモリである。メモリなら交換がきくが、マザーボードとなると、同じものは用意できないだろう。なにせ 6 年前だからなぁ……。

あと不思議なのが、ブルースクリーンが出たあと再起動すると、しばらく使えるのよね。三日間とか。短くても丸一日持つ。
まずやるべきはメモリチェックなんだけど、厳密なメモリチェックは一日作業だ。その間、サーバを停止させるわけにもいかない。なので搭載メモリを MAX まで使うような処理をしてみているんだけど、それでも飛ばない……。

で、いろいろ検索した結果、こんなページを見つけた。

ただねー、ボクの心はこれじゃない、って騒いでるｗ
絶対ハードウェアの何かが壊れてるって、もう頭の中じゃ解ってる。
けど一縷の望みをかけて、当ててみた。

すると、これがまたしばらくサーバは動き続けるんだよなー（汗
というわけで、このサーバ対応、別の日に続きます（つまり上のでは解決はしなかったということだｗ

1610071849

▼関連記事

目が覚めたらブルースクリーンだったでござる お料理は、美味しいだけではダメですよね…サーバのブルースクリーン問題、解決する WordPress の spam 状況 DB を SSD に移行した

目が覚めたらブルースクリーンだったでござる

大和 環Leave a comment

ふと朝、目が覚めて、なんとなーく枕元のノート PC でネット見ようと思ったら、なんか見られない。んー？ Wi-Fi がおかしくなったか？ とか思いつつも、右下の Skype のアイコンを見たらオンラインだ。あれー？ ネットは死んでないみたいだぞ？

で、すぐに DNS かなって思って、サーバに ping を飛ばすと反応がない。
なんだこれ……と思ってサーバのモニタを見てみると……なんか真っ黒い画面にワケわからぬ一文が……。しかしまだ寝ぼけていたせいもあってそれをメモるの忘れたのよね……orz

で、再起動したら、ブルースクリーンが……！！

ぎょえー！ まだ代替サーバ買ってないよ？？

エラーコード 0x1A はあってないようなもの。なんつーか、よく解らないけどなんかヤバいよ的な？ ドライバの可能性もあるし、ハードウェアの可能性もあるしという非常に漠然としたヤツなのだ。ただ、メモリかなーなんてちょっと思った。あと画面が壊れかけているから、ビデオカードの可能性も。ただビデオはオンボードなので、ビデオ周りが故障してた場合はマザーボードの故障と言うことになり、非常に厄介だが……（大汗）。
とりあえずサーバを長時間落として置くわけには行かないので、メモリチェックはやめて（凄い時間がかかるので）、強硬手段に出た。それはメモリを MAX まで使ってやること。
というわけでサーバが起動したら、全ストレージに Chkdsk というコマンドを実行する。このコマンド、裏で何をやっているのかよく解らないが、メモリをすげー食うんだよね。とくにでかいサイズのディスクをやると、あっという間に 16GiB 使っちゃう。

が……飛ばない。アレー？
その後、ログをみるも、朝の 5:30 頃にぴたっと記録が止まっているだけで、何が原因かサッパリ解らない。

とりあえず 2 時間ほど様子を見たが、特に飛ぶ気配もないし、サービスは全部動いている。
なんだったんだー？？
熱暴走？？ それともたまたまメモリからのデータが壊れたとか？？

1608181091

で、まぁ、秋葉に着いたのが 13:00 頃だったので、ついでに秋葉で飯食おうとなった。実は前日、ウチの会社の別の開発室のハブが壊れて、秋葉に買いに来ないといけなかったのだ（一応会社のネットワーク管理をサブでやっている）。
というわけで、万豚記（ぁ
なんか秋葉というとここでしか食べてないよな、最近（汗

なんかフワッとした卵料理が食べたかったので、キクラゲと卵と豚肉の炒めを頼む。
ほとんど望み通りだったんだけど、味付けがけっこうあんかけ的なヤツだった。ボクはもうちょっと野菜炒め的な？ 味付けも塩ベースか醤ベースを期待していたんだけど……違った。
でも美味しく食えた。しかしあんだから熱い（汗）。冷房効いてるのに汗かいてしまった。

1608181092 1608181094

▼関連記事

たぐり庵 リバースプロキシって便利！ 南国亭の固焼きそば Domain Controller の長い話と新田毎と地下鉄