MTSファイルが容量を圧迫

ども。
めっきり寒くなり、健康管理に気をつけている担当ちゅんです。

本日は困った案件を一つ。職員が利用しているファイルサーバがあるのですが、このところ空き容量が切迫していて、この対応に追われています。Windows Serverにて運用しているものなのですが、あまりにも空き容量が少なすぎてシャドウコピーすらも満足に動かない状況です。

こういう状況は、少なからず当町だけに限った問題ではないと思われます。私がこの部署に来た10年前と比べて、業務の中で扱われるファイルの量は増加していますし、それに加えて「永久保存」としてずっとサーバ内に保存され続けるファイルも年々増えていきます。さらに、従来はテキストデータが主体だったものが、今では「画像」「動画」など1ファイル当たりの容量が大きなものが増えてきています。つまり、そういう時代になったということでしょう。

それでも、悠長に構えてはいられません。ファイルサーバの中を点検して、どこかに削除可能な巨大ファイルが隠れていないかを点検します。探し方は以前このブログで教えてもらった方法です。

(参考)
情報政策室ブログ:サイズの大きなファイルを探せ(解決編)
http://www.town.yakumo.lg.jp/modules/information_blog/details.php?bid=1956

検索してみると、ずらっと表示されたのは拡張子が「MTS」のファイル。中には1ファイルあたりおよそ2GBも消費しているものがあるなど「これではディスクがいくらあっても足りない」という状況。

そもそも「MTSファイルって何?」という話ですが、ハイビジョンに対応したデジタルビデオカメラ等で扱われるデータ規格「AVCHD」で保存された動画のファイルです。録画した後に動画編集するなどの用途では高精細なデータを劣化させることなく取り扱えるといったメリットがあるのだと思いますが、高精細な分だけファイルサイズは大きくなってしまいます。
本来であれば、このファイルはそのまま保存しておくようなものではなく、例えばDVDやブルーレイといったディスクに書き込んで保存するとか、もしくはMP4など別な動画フォーマットに変換(エンコード)するなどの方法でサイズを圧縮するのが普通です。
今回、このファイルが大量に見つかったところで、これからどうすべきなのか頭を悩ませているのです。

最低限、職員の皆さんに協力してもらい、不要なMTSファイルは削除してもらう、必要なものはメディアに書き込んで保管してもらうなどの方法をとらなければなりません。しかし、個人的にはデジタルビデオカメラの段階で外部出力する際にどうにかならないものかと感じます。正直、MTSファイルを必要とするユーザーってどのくらいいるのでしょうね・・・。
そもそも、ユーザー側にエンコードまでを求めるのは、情報システム担当として正しい考え方なのかどうか、そこも悩ましいところです。

MTS
こんなのがゴロゴロ。ある意味で「宝の山」に見えました(空き容量を増やせる余地という意味で)

(投稿者:ちゅん)

カテゴリー: つぶやき | 2件のコメント

不具合の原因は熱暴走?

ども。
いつもブログをご覧いただいている方のなかで、とても参考になるメールをくださる方がいらっしゃいます。この場でもお礼申し上げます。本当にありがとうございます。担当ちゅんです。

さて、当町では防災などの目的に利用するために、町内各所にネットワークカメラを設置して運用を行っています。基本的にはインターネット側にはおかず、クローズドな業務用のネットワークに設置しています。
先日からそのネットワークカメラのうち1台が不調となり、しかもそのタイミングで台風が接近する事態となり、防災の担当者には「肝心なときに満足に動かなくて申し訳ない!」と頭を下げていた状況でした。

思い起こせば、不調となったのはお盆前頃だったように思います。そのカメラには屋外無線LANにてネットワークが提供されていて、基地局側との距離は200m、見通しには障害物は皆無という好条件です。それにも関わらず、PINGを通してみると10本中1本くらいしか通らなくなりました。カメラの画像は辛うじて見られるものの、安定して閲覧できません。こういう時に思うのですが、壊れるならばいっそ全く動かなくなってほしいと感じます。PINGが「たまに通る」という状況は、原因を探ろうと思うとかなりの数の検証作業が必要となり、保守要員泣かせだといえます。

色々と検証した結果、今回の場合はどうやら不調なのはカメラ本体ではなく、屋外無線LANであるというところまで行きつきました。そこで、無線APの代替機を用意して、既設機器と全く同じ設定を行い、物理的に取り換えてみるということを考えました。
さっそく、機器に設定を行います。本件の屋外無線はWDS専用モードにて接続され、あらかじめ設定されたMACアドレス機器にのみ通信が許可されるようになっていました。IPアドレスなどは全く同じ設定にできても、MACアドレスだけは追加で登録が必要です。
そこで、無線LANの親機にMACアドレスを登録。設定画面から入力をし、OKボタンを押すと、自動的にAPが再起動しました。

事前準備が整ったので、さあこれから現場に向かいましょうと思ったそのとき、ずっと通していたPINGが1本の欠損もなく見事に通っていることに気がつきました。
全く意味が分かりませんでしたが、思い当たる節としては「APが再起動した」ということくらいです。
これまで、てっきり原因は不調になったカメラ側に設置していたAPであるとばかり思っていました(根拠も多少はあったのです)が、どうやら親機の方に原因があったようです。再起動で直ってしまったということは、この辺の方言でいうところの「こんつけてた」ってことでしょうか。あらためてAPを設置していた場所を確認すると、建屋の高い位置に取り付けていたBOX内で、しかも西日が直接当たる場所。・・・もしかして熱暴走だったのでしょうかね。

原因のAP
こんな場所に取り付けられていました。暑そうですよね。

(投稿者:ちゅん)

カテゴリー: つぶやき | コメントする

停電で発生した謎のサーバトラブル

ども。
睡眠時にネックウォーマーをしてみたところ、肩こりが幾分和らいだ担当ちゅんです。

9月に発生した大規模停電(ブラックアウト)では、様々なトラブルに見舞われました。中でも腑に落ちないのが「仮想サーバがダウンした」トラブルです。

前提条件として、当たり前ですが仮想サーバをホストしている物理サーバやストレージ、スイッチは全て無停電電源装置(UPS)に接続され、そのUPSのバッテリーが尽きる前に庁舎の自家発電設備からの給電に切り替わるようにしてあります。こちらの想定では、仮に停電してもサーバはダウンせずに起動を続けられるようにしてありました。

しかし、今回の停電では物理サーバは正常に稼働を続けていたにも関わらず、Hyper-Vで動かしていた仮想サーバのうち、いくつかのサーバだけがダウンしてしまいました。手動で再起動をかけると無事に起動してくれたので事なきを得たのですが、止まってしまったことがショックでした。

その後、サーバの保守業者さんとともに原因の調査を進めました。停電の前後に記録された機器のシステムログを確認すると、どうやらストレージのNICがリンクダウン・リンクアップを繰り返している状況が記録されていたようです。つまり、仮想サーバのデータが保存されたディスクが急に取り外された状態となり、サーバが停止してしまったということのようです。
このことから、業者さんからは「もしかしてストレージがUPSに接続されていなかったのではないですか?」と質問されましたが、確認してみると間違いなくUPSに接続されていました。そもそも、これまでも庁舎が停電することはありましたし、その際にストレージがダウンしたことなどありませんでした。

ここで、業者さんから「もしかしたら」と仮説が。ストレージがダウンしたのは停電が直接の原因ではなく、停電に至るまでのわずかな間に電力供給が不安定になったことに起因しているのではいか、とのこと。はっきりした原因は結局のところわかりませんが、もしこの仮説が正しければ、我々にはどうすることもできなかったということになります。
ちなみに、この同様のトラブルは役場だけではなく、別な場所の仮想サーバでも発生しました。こうなるとますます謎が深まります。いずれにしても、やはり「万が一止まった時にどう復旧させるか」が大切なのであり、そういう意味でICT-BCPの重要性を再認識しています。

Hyper-V
この画面を見たときは、一瞬目の前が真っ暗になりました。

(投稿者:ちゅん)

カテゴリー: つぶやき | コメントする

パソコンが手に入らない?

ども。
職場では電話ばかりで受話器を持つ手が筋肉痛になる勢いの担当ちゅんです。

先日、とある機器更新の案件の中で気になることがありました。その事業は比較的大規模なもので、納期も余裕をもって進めてきたのですが、業者さんから「もしかしたらノートPCの調達が間に合わないかもしれない」と連絡を受けたのです。

そのときは結果として、納期ギリギリになってなんとか納品され事なきを得たのですが、遅れた理由をお聞きして驚きました。なんと「世界的にCPUが品薄になっている」とのこと。実際にTech系サイトなどを確認してみると、かなり大きな話題として取り上げられておりました。お恥ずかしい話ですが、私はそれまで全然知りませんでした。

本日情報交換をした業者さんいわく「特に国内メーカーの納期が大変で、早くても2か月半待ち、最悪は納期未定とされていて、商談しようにもままならない」とのことでした。そうですよね。発注する側の想定とすれば「だいたい1か月、長くても2か月あれば安心」という認識で仕様書を作成しますが、それにモノが間に合わないということは、最悪「入札辞退」となってしまう恐れがあります(というより、そもそも入札が成立しない場合も)。こちらとしても、こうした状況であることを知らずにうっかり調達案件を進めてしまうと、とんでもないことになってしまいそうです。

自治体では予算要求の時期に差し掛かり、機器の更新を予定されている部署からPCの価格などを相談されることが多くなりますが、この価格だってどう考えればよいのかわかりません。PCが品薄になっているということで考えれば、当然値段そのものも上昇してくることが想定されます。それでも実施しなければならない事業はあり、その場合は「タイミングが悪かった」という話かもしれませんが、こちらとしては何もできないのがもどかしいところです。

CPU
CPUのことを業界では「石」と呼びます

(投稿者:ちゅん)

カテゴリー: つぶやき | コメントする

結果としてすぐに覚えた

ども。
10月に入ったとたんに冬の到来を感じている担当ちゅんです。寒いです。

昨日から、我が職場に新たな仲間がやってきました。ブログ上での呼び方はまだ決めていませんが、これから徐々にお披露目していきます。
これまで、情報部門とは全く違う職場で仕事をしてきており、知識も経験も一切ない状態での異動となりました。ゆっくり焦らずに、楽しみながら仕事を覚えてもらえれば嬉しいです。
私自身も10年前に同じ状況であったことを思い出しながら、当時の上司から何をどのように教わったのかを思い出しながら仕事にあたっています。

そんな中、昨日はこの部門で最も重要な「管理者IDとパスワード」を伝えました。専門的にいえば「Domain Admins」のパスワードになりますので、情報担当者以外には門外不出、部外秘中の部外秘になります。これが外部に流出したら、サーバーから何から、すべてにフルアクセスできるようになってしまいます。
当たり前ですが、知らない人からは想像できないようなランダムな文字列です。私はすっかり身についているので、指が勝手にキーボードを叩く状況ですが、彼にとっては覚えるのに一苦労。「そのうち覚えるから」と伝えたのですが、その後、よもやの事件が発生することになります。

何が起きたのか。とあるシステムがあり、そのシステムには専用のタブレットをUSB接続してデータ連携しています。業者さんいわく「1年に1回程度の頻度でUSB接続が必要となり、その際に『数回』、ユーザーアカウント制御画面で管理者IDとパスワードを入力していただく必要があります」とのことでした。
今回、その仕事が出てきたので、ちょうどいい機会だと思って彼に「やってみるかい?」と。二つ返事で「やります!」とのことで、見守りました。

さっそくその場面になり、IDとパスワードを入力。するとすぐに再度入力画面が出てきて、また入力。それを5回も繰り返したころ「あれ?」と思いました。何度入力してもすぐさまIDの入力が求められます。
確認してみると、どうやらシステム側の仕様(という名の不具合)により、タブレットに保存された画像データの個数分だけIDの入力が必要とわかりました。
本来であればすぐにあきらめ、Windowsそのものに管理者としてサインインしたうえでこの作業を行えばよい話ではありますが、今回は「練習だと思ってやってみたら?」ということに。結果、彼は50回以上も管理者IDとパスワードをひたすら入力する結果となってしまいました。そのおかげか、そのうち覚えるはずのIDとパスワードを、すっかり覚えてしまう副産物が得られました。にわかSEに必要な「忍耐力」が試される一日になったようです。

管理者アカウント
この画面にひたすら入力を繰り返すこと小1時間・・・。

(投稿者:ちゅん)

カテゴリー: つぶやき | コメントする