2016年04月10日(日) - 21:20 | カテゴリ:
PC
昨日、リファビッシュが戻って来たNAS用HDDだが、
他の容量小さいHDDが枷になり、容量をフルで使う事が出来なくなっていたので、
容量小さいHDDを載せ替える為にHDDを買いに行ってきた。
そして、HDDを買った後アキバをブラブラしていたら、
BUY MORE恒例のジャンクCPUガチャをやっていたので、手持ちの100円玉を10枚ぶち込んできた。
クリアファイルを買ったら、HDDが付いてきた。
こっちは今まで通りDroboFSに突っ込む予定 ﾍ(ﾟ∀ﾟﾍ)
1発目のCPUガチャは、Core2Duo E6700 2.66GHz
確か、2006年発売なので10年前のCPU。もうそんなに時間が経ったのか…
E6700はE6600と比較した時に料金が高かったり、高い割には性能比は振るわなかったりで、
この型番については、お祭り状態にはならなかった印象。
2発目のCPUガチャは再び、Core2Duo E6300 1.86GHz
こちらも自作パーツとしては日の目を見る事が少なかったが、
一部のメーカー品では標準部品として組まれていたので、知らぬ間に使っている人は多そう。
ちなみに、Core2DuoのCPUが発売された時のアキバはこんな感じのお祭り騒ぎでした。
………
今のCoreシリーズが主流の時代に、敢えてCore2Duoを使う人は少ないと思うが、
ジャンク屋に行くとLGA775の保守用未開封マザーボードが投げ売られていたり、
年代の割には品質の良い物が格安で手に入るのが魅力。
Web閲覧用途では、Flash使っていないページだと通用するスペックだし、
(電気代に目を瞑れば)サーバ用ととして十分通用する処理速度を誇っているし、
軽く1台組むには良いのかもしれない。
………
他には、やっちゃばフェスをやっていたので同人誌を買ってきたり、
Character1のパンフレットを貰ってきたり。
今年のChara1は、1箇所お目当てがあるので朝っぱらから参戦する事になりそうな予感。
« 続きを隠す
2016年04月09日(土) - 00:20 | カテゴリ:
自作PC
NASに使用していたWD Purple 2TBが2月辺りに昇天してしまい、
「NAS昇天はマズい。溜めた画像やら動画やらが…」という事で急遽秋葉原まで行き、
代替えのHDDを買いに行っていたのでした。
普段ならここで終わりなのだが、今回壊れたWD Purple 2TBはRMA期間内だったので、
約3年ぶりにHDDのRMA交換をやってみた。
そして、3年ぶりにRMA交換をやったら手順が変更されていたり、
送付先が国際便でマレーシアではなく、日本内の倉庫に送りつける方針になっていたり、
色々と便利で楽になっていて驚いた ( ﾟдﾟ)
戻って来たHDDは、RMA交換レポートで良く見る段ボールだった。
RMA手段については都度変化する物だし、ググれば先人が公開しているので今回は割愛。
今回壊れたのは↑のHDD。2015年6月製のWD紫2TB。
NASで使っていたので、24H365Dで電源入れっぱなし状態。
そして、WDのポータルからRMA申請を行い、国際郵便用のインボイスとかを作っていたのだが、
住所を良く見ると英語標記ではるが、HDDの送信先が海外から国内へ変更されている事に気がついた。
という事で、敢えてEMSで送る必要も無いのだろうと思い、
クロネコヤマトの伝票に、日本語住所を記載し、そのまま国内住所へ送りつけてみた。
その結果、送りつけてから2週間少しの期間で、交換のHDDが国際郵便で自宅まで届いたのでした。
………
戻って来たHDDは厳重に梱包されていた。
この箱とクッション材が次回RMAする時に重宝するので保管せねば。
戻って来たHDDは、Recertifiedのタグが付いた同型品だった。
↑の画像ではモザイクになってしまっているが、製造年月は2016年3月。
戻って来たHDDをスライディング裸族に装着して、1日程稼働させ続けた後のSMART値。
どうやら、IntelliParkも悪さをしていない模様。
送料はかかってしまうが、壊れたHDDが(リファビッシュだが)新品同様になるので、
これを使わない手はないだろう。
次はどのメーカーのHDDが壊れるか判らないが、
RMA期間内だったらまた申請してみる事にしよう。
« 続きを隠す
2016年03月27日(日) - 16:25 | カテゴリ:
Linux
前回：ns-labのMTA鯖を拠点冗長化してみた
今までは↑の構成で問題無かったのだが、
昨日S氏とプライベートの待ち合わせをしている時に、
S氏「(自鯖に)メール送ったんだけど、届いていないっぽい」
自分「スパムフィルターで除外されたかな? もう一度送っておくれ」
S氏「送った。 どうよ?」
自分「届かぬ…」
というやり取りがあり、色々と原因をシミュレートしていた所、
修正前の構成ではVPNが切断された場合、メール配送が著しく遅延する事に行き着いた。
というのも、ConoHa側に着地したメールは固定配送(DNS指定)を切って、
ドメイン毎にVPNを通過させつつ、SpamFilterへ着地されている。
その為、VPN接続断の状態だとConoHaから先が無くて、ConnectionTimeoutになってしまっていた。
ちなみに、今までは固定配送先のDNSレコードを自動切り替えして対応していたのだが、
ここの所プライベートでも自鯖メールを使う様になり、
このままじゃマズイという事で、良い機会だと思って配送経路も冗長化してみた。
という事で配送経路を修正した結果がこちら。
経路上では難しい事はせずに、普通に迂回させる方針にしてみた。
|
|
|
通常配送
|
VPN障害時
|
普通の設計なら、VPNを安定化させて接続断を極力起こさないようにしたり、
そもそもVPNを経由させずにInternetで配送させる筈。
しかし、ns-labの場合はVPN-GWで少し細工したり、VPN接続性の実験を常にしている為、
通常のメールについても出来る限りVPNを通したい経緯があった。
………
試行錯誤している中で、固定配送を冗長化する設定で大きな問題が起きた。
それは、Postfixではmailertableの様に固定配送先を複数設定するのが普通は出来ないという事。
厳密には固定配送先が1つまでなら、"transfer_maps"のみで出来るけれど、
似たような事をするには、master.cfを弄ったりと面倒臭い事がわかった。
最終的にはmailertable相当の事が実現出来たのだが、
何故Postfixでtransfer_mapsを書く時に複数の配送先を指摘出来ないのが、
今回の設定を作る上でハマる要因の一つだった(´・ω:;.:…
………
メールとDNSは昔からある仕組みだからこそ、複雑だしいたる所にハマる要因があるのが怖い。
ns-labのメールサーバは特殊な構成だし、シンプル構成への組み替えを考える頃合いなのかもしれない。
…と言いつつ、複雑だからこそ判る事もあるので、このまま突っ走る予定ではありますが ﾍ(ﾟ∀ﾟﾍ)
« 続きを隠す
