ハードディスクメンテナンス

ハードディスクの診断、物理フォーマット、静音化、Linux、サーバー、MySQLなどがメインだったのですが、その後広がり、カメラやハードウェアの投稿も増えてきました。 モバイルデバイスは、MacBookAir(13型)、iPad Air2、ポメラ DM100(キングジム)OLYMPUS STYLUS XZ-2など。 これらを使いながら、ブログを更新しています。

カテゴリ: Linux



現在運用しているWEBサーバーやデータベースサーバー、ファイルサーバーは、常時起動である。

常時起動のサーバー

サーバーといえどもパソコンなので、故障する。

過去に運用してきた経験では...

一番多いのが、やはりディスクの故障。



即●ではなく、S.M.A.R.T.の一部に異常が出るパターン。

関連:ローレベルフォーマットによるS.M.A.R.T.の変化(代替処理保留中のセクタ数,代替処理保留中のセクタ数,回復不可能セクタ数)

この場合、

動作に問題はない場合と、問題が出る場合がある。

ディスクは不良セクタが出ることを見込んで製造されているので、不良セクタが発生しても、代替処理することができる。

不良セクタが発生した箇所にあったデータが生きており、それが代替処理されれば、特に問題なく動く。

但し、この場合でも、不良の発生したディスクは交換すべきだろう。

問題が出るのは、不良セクタが発生した箇所にあったデータが破損してしまった場合。

これが運悪く起動に必要なファイルであると、起動に失敗する。

MySQLに必要なファイルであれば、MySQLが起動できなくなる。

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド
奥野 幹也
技術評論社
売り上げランキング: 32,202


このようなトラブルに備えるため、ミラーリング(RAID1)を組んでおく。

RAID1やRAID5は、故障しても許されるのは1台のみである。

2台以上壊れると、データは失われてしまう。

RAID5のリビルド時に生きているディスクに負荷がかかり故障し、データを失ったという話はよく聞く。

リビルド時は、普段よりもディスクに負荷がかかるので、その時に故障してしまうのだ。

RAIDを組んでいたとしても、確実に復旧できるとは限らない。

そんな時のために、別途バックアップを取っておこう。

RAIDには、ソフトウェアRAIDやハードウェアRAIDがあるが、Linuxであれば、ソフトウェアRAIDが使用可能。

# ソフトウェアRAIDやハードウェアRAIDの定義は、実は曖昧なのだが。

ハードウェアRAIDの場合、そのコントローラが壊れてしまうと?



次に多いのが、電源の故障。



関連:PowerEdgeT105の電源不良 2台連続 L305P-01 NH493 PS-6311-5DF-LF

マザーボード上の待機ランプが点灯するので通電はしているようだが、電源が入らない。

特定のモデルでの不良が重なっただけかもしれないが、電源も消耗品だ。

電源の冗長化がされていないサーバーであれば、予備電源の保管は必要だろう(ダウンタイムは生じるが)。

メモリーのエラーは、サーバーではないがクライアントでは経験した。

現象は、不安定になるとか、起動しないとか。

メモリーが原因と特定するのは、かなり大変だ。

最近のWindowsにはメモリーチェックツールが備えられているが、Memtest86でチェックするのがよいだろうね。

関連:Memtest(Memtest86)でのメモリチェック(診断)方法の日本語解説

Memtest86は昔からあるメモリーチェックツールで、フロッピーやCD-ROMで起動させたものだが、最近のノートパソコンだと、どちらも搭載していないこともあるので、USBメモリーから起動させよう。

最近は少ないだろうが、チェックOKのメモリー2枚を同時に挿すとNGとなる場合があるので注意(メモリーの相性問題)。

サーバーにはECC(Error Checking and Correction)付きのメモリを、とはよく言われる。



関連:PowerEdgeT105のメモリー換装(動作確認メモリーの型式)

ECCメモリーとは、エラーの検出と訂正を行なう機能を持っているので、確かにそうではあるが...

ECC付ではないメモリーを使用したサーバーも何台か運用している。

メモリー上で破損したデータがDBに格納されると困ることなるからね。

サーバーにどのくらいの重みを持たせるかで変わってくるだろう。

変わった不具合としては、電源断で再起動した際に、BIOSの設定が飛んでしまい、IDEモードで設定していたディスクモードがAHCIになってしまい、起動に失敗することがあった。

Debianだと、grubの後で停止してしまう。

普段出現しないはずのAHCIの認識画面が表示されるので気付くが、普段見ていない者は気付かないかもしれない。

レンタルサーバーやクラウドに移行すると、これらハードウェアの保守は不要になる。

何かあっても、ハード面は業者が見てくれるからね。

但し、メンテナンスとして、ダウンタイムが発生することがある。

多くは深夜から早朝に行われるので、社内用途では影響ないことも多いが、WEBサービスだと困る。

ハードウェアが社内にあると、保守が必要であるし、それに明るい技術者が必要になる。

保守を外部に任せるというのもあるが、即座に来てくれるのかどうか。

翌日営業日対応であるとか、当日4時間対応、定期訪問などがある。

DELLの保守サービス


  • 当日対応オンサイト保守サービス

  • 当日4時間対応オンサイト保守サービス(6営業日 9-17時)

  • 当日4時間対応オンサイト保守サービス(24時間365日)

  • 当日4時間プラス対応オンサイト保守サービス(6営業日 9-17時)

  • 当日4時間プラス対応オンサイト保守サービス(24時間365日)



関連:DELLの保守サービス

保守は保守で重要であるが、保守は評価されにくい(営業とは異なり売上が増えるわけではない)ので、有料保守サービスに対する上の理解が得られない場合も多い。

上がハード関連に無知であれば通るが、中途半端に詳しいと、そのくらい自社でヤレ!となって、これまた中途半端に詳しい事務員なんかが「管理者」になってしまう罠w

障害報告を受けても、話が通じない罠www

サーバーは問題なく動いていても、通信できなければ意味がない。

NICの不良は経験がないが、HUBの故障はよくある。

特にGigabit初期のHUBはよく故障した。

発熱が大きかったからだろうか。

面倒なのは、通電直後は通信できるが、しばらくするとダメになるパターン。

NICだけでなく、HUBの冗長化も必要だね。



有線LANがない端末は仕方がないが、サーバーを無線(Wi-Fi)でつなぐのはやめてくださいwww

ケーブルが嫌いなのは分かりますけど。

CPUの故障は、コア欠け(昔のAthlonなど)以来、ここのところ経験していない。

ファン交換時に付け直したグリスがCPUのLGA側に付着し、CPUは認識するものの、メモリーの一部が認識されないという経験がある。

メモリスロットの一部のみが使えないのだ。

グリスを塗る際は、CPUの裏面に付着していないか、LGA側にも付いていないか確認しよう。

マザーボードの不良も、サーバーに於いてはこのところ経験していない。

クライアントではUSB周りをはじめ、不良を経験しているが。

関連:Renesas(ルネサス)のUSB3.0(MPD720200)のドライバの更新(不具合解消)

サーバーなので、特殊な機能やチップ追加での強引な機能追加はよろしくない。

スイッチチップで速度を上げるとか。

数年前はそのようなマザーが多かったが、最近は枯れており、問題ないだろう。

サーバー用のマザーは、変なもの付けないしね。

コンデンサーもアルミコンデンサーから固体コンデンサーに置き換わっているので、コンデンサーの破裂やドライアップが原因で不安定になることもないだろう。

まぁ、メモリーやハードディスクは予備があれば交換できるが、マザーボードが故障した場合、同型のマザーボードの予備を持っていることは少ないと思うが...

マザーが壊れないことを祈ろうw

サーバーを導入したら、負荷を掛けて安定することを確認してから、実環境に投入するようにしている。

できるPRO CentOS 6 サーバー (できるプロシリーズ)
辻 秀典 渡辺 高志 できるシリーズ編集部
インプレスジャパン
売り上げランキング: 53,086

[PR] au PAY / au WALLET カード 情報

このエントリーをはてなブックマークに追加 mixiチェック



昔に比べるとLinuxも随分簡単になり、GUIで操作できる部分も増えた。

黒い画面に文字を打っていた(CUI)、ユーザーの追加も、今はGUIでできるしね。

Windowsかwwwww

しかし、GUIで全てを操作できるかといえばそうではないし、操作できるように見えて実はできないとか、GUIなので操作が簡単かと思いきや複雑であったり。

Ubuntuまで割り切ればよいが、Debianだと割り切れないしね。

Debianはサーバー用途での採用が多いと思うが、サーバー用途ではそれなりに細部を設定することになる。

中途半端にGUIで操作できるのも、考えものだね...

例えば、DebianをGUIインストール時にRAIDを組む場合がそうだ。

パーティションを切ってからRAIDを組むのだが、いつも悩む。

項目のダブルクリックで操作できる部分があるが、ダブルクリックで行うのか、下のボタンを押すのか、等。

CUIよりは「楽」ではあるが、画面の構成とか、操作方法に一貫性がないというか。

CUIでの操作は一般的に敷居が高いので、CUIのままでは利用者が増えないだろう。

ということで、徐々にGUI化を進める必要性は分かるのだが。

GUI化の遅れ→使いにくい→ユーザー増えず、という流れ?

Linuxシステム[実践]入門 (Software Design plus)
沓名 亮典
技術評論社
売り上げランキング: 64,605

[PR] au PAY / au WALLET カード 情報

このエントリーをはてなブックマークに追加 mixiチェック



Debian(7.5)サーバーを再起動したら、ブート途中で死亡。

Debianの起動に失敗
この状態で止まってしまう

どうも、ブートに必要なファイルが読み込めないようだね。

このサーバー、ソフトウェアRAID(ミラー)を組んでる。

sdaとsdbの2台(スペアはなし)。

BIOS上では、2台とも認識はされている。

そのどちらに問題があるのかを確かめるため、sdaを切り離して起動させると、同じ画面でコケる。

よって、sdbが異常と判断。

sdbを取り外し、sdaのみとすると起動することを確認。

ただ、この状態では片肺で危険なので、速やかにハードディスクを追加する必要がある。

しかし、同型式のハードディスクがなかったので、同容量のディスクを追加。

# 同容量以上であれば、他のメーカーや型式のハードディスクでも構わない。

ハードディスクを追加し起動させ、ディスクの管理画面(ディスク・ユーティリティー)へ。

左の下方にあるミラーを選択し「%d個のコンポーネント」を編集をクリック。

スペアを追加すると、リカバリ中となり、リカバリが進行する。

リカバリ完了後、grubをアップデートし、sdbにもインストール。

update-grub

grub-install /dev/sdb

これをしておかないと、sdaが逝った場合に、sdbから起動できないのだ。

それでは、ミラー組んでる意味ないよね。

ミラー領域に起動パーティションが含まれている場合は、パーティション・フラグを「ブート可能」にする。

この後、スペアとしてsdcも追加しておく。

ミラーを選択し「%d個のコンポーネント」を編集をクリックすると、sdcをスペアとして追加できる。

スペアを追加した
スペアを追加した

スペアとして追加されたsdcは、sdaやsdbが逝った場合に、自動的に上がってくれる。

当然、sdcには電源ケーブルとSATAケーブルの両方を挿しておかなければならない。

通電している以上、sdaやsdbよりも先にsdcが逝ってしまう可能性があるが...

sdcにも、grubをインストールしておく必要がある。

update-grub

grub-install /dev/sdc

そして、パーティション・フラグを「ブート可能」にする。

以上で復旧は終了。

[PR] au PAY / au WALLET カード 情報

このエントリーをはてなブックマークに追加 mixiチェック



DebianMySQLを入れてDBサーバーとし、ローカル環境に置く。

試験サーバーをローカルに立てて、作業用端末からアクセスすることはよくあることだ。

が、デフォルトでは、MySQLの入った端末からは当然アクセスできるが(自己内)、ローカル内の他の端末からはアクセスできない。

これを可能にするには、MySQLの入った端末(DBサーバー)の

/etc/mysql/my.cnf (MySQLの設定ファイル)

を編集する。

なお、Debianに限らずLinuxでは、/etcは設定ファイルを格納するディレクトリである。

/etc/mysql/my.cnf



bind-address = 127.0.0.1

という記述があるので、これを削除するか、先頭に#(コメント行)を付けて、

# bind-address = 127.0.0.1

とし、

/etc/init.d/mysql restart

で、MySQLの再起動。

再起動後、DBサーバーに接続できるかを確認する。

これで解決はするのだが、このbind-addressは、接続したいMySQLが動いている端末のIPアドレスであり、接続を許可するIPアドレスではないのだ。

従って、接続できる端末を増やそうとして

bind-address = 127.0.0.1

bind-address = 192.168.0.10

bind-address = 192.168.0.20

と併記しても意味がない、というか、そもそも無効。

繰り返すが、bind-addressは接続を許可するIPアドレスではなく、これで接続してくる端末のIPを制限するものではない。

なお、MySQLの入った端末(DBサーバー)にApache等のWEBサーバーが入っており、そのWEBサーバーからMySQLにアクセスする場合は、自己内なので何もする必要はない。

MySQLの入った端末(DBサーバー)が複数台あり、各々他方へアクセスするような場合も、上記の設定変更が必要。

MySQL全機能バイブル ~現場で役立つAtoZ~
鈴木 啓修
技術評論社
売り上げランキング: 199,175


[PR] au PAY / au WALLET カード 情報

このエントリーをはてなブックマークに追加 mixiチェック



DebianのユーザーID(uid)の範囲と定義は、

0:ルート
1-99:Debianのシステム
100-999:システム
1000-29999:一般ユーザー
30000-59999:予約済
60000-64999:Debianのシステムによって一時的に作成するため
65000-65533:予約済
65534:nobodyが使用
65535:使用禁止

昔はこんな感じだったが、今もそうなのだろうか?

rootで作業することは避けるべきなので、必要に応じてユーザーを作成する。

最初に作成するユーザーのIDは、普通は「1000」になるはずだ。

FFFTP等のFTPクライアントの画面では、所有者としてこのユーザーIDが見られる。

FFFTP

上は、/etc/exim4 を見たところ。

右端の「所有者」が「0(root)」になっているのが分かる。

所有者と属性に注意しないと、編集できない(上書不可)、削除できない等の問題が生じる。

Linux初心者にありがちなトラブルだね。

「rootで作業することは避けるべき」とあるが、これは、rootは最高の権限を持つユーザーであり、全てのデバイスやファイルにアクセスできるため、システム破壊も可能。

よって、普段の作業は別ユーザーで行い、必要な時にsuやsudoでコマンドを実行する。

同じ理由で、FTPでrootで入ることはデフォルトではできないようになっている(設定で変更)。

GUIで、重要なファイルをカンタンに削除可能♪

また、rootで入った際のパスワード漏洩の危険性もある。

一般ユーザーのパスワードが漏れても(権限が制限されているので)被害が少ないが、rootが漏れると何でもできるので被害甚大!

それなりにLinuxを使うようになってくると、rootでないと何もできないwww

自宅サーバーなら、常にrootで作業している人が多いのでは?

su は他のユーザーに「変身」。ユーザー名の省略でrootに変身。

但し、その際にrootのパスワードを求められる(rootパスワードが漏れる危険性)。

sudo は、rootのパスワードを入力することなくroot権限のコマンドを実行できるが、/etc/sudoersにそのユーザーの登録がないと、以下のようにはじかれてしまう。

[sudo] password for test:
test is not in the sudoers file. This incident will be reported.

この場合、rootで入るか、またはsuで「visudo」と打ち、/etc/sudoersにsudo可能なユーザーを追加する。

# はコメント行。

root ALL=(ALL) ALL

という記述が見つかるが、同様に

test ALL=(ALL) ALL

を追記すると、testに全てのコマンドのsudoによる実行権限を与えることができる。

%sudo ALL=(ALL) ALL

と、頭に%が付いた記述があるが、これはグループね。

sudoグループに属するユーザーは、全てのコマンドのsudoによる実行権限を持つということ。

ユーザーが多い場合、グループを使った方が管理が楽だね。

Linuxシステム[実践]入門 (Software Design plus)
沓名 亮典
技術評論社
売り上げランキング: 23,323


[PR] au PAY / au WALLET カード 情報

このエントリーをはてなブックマークに追加 mixiチェック

このページのトップヘ