【社内資料公開】AWSトラブルシューティングページまとめ／より早い原因把握のために心がけること | DevelopersIO
はじめに こんにちは植木和樹です。オンプレで10年近くサーバーの保守運用をやっていた経験からいいますと、AWSの障害発生率は非常に低くて驚きます。数百台規模のサーバーを扱ってますと、毎日どこかでのサーバーでディスク、CPUファン、メモリーパリティエラーなんかの故障が起きていて日々対応に駆けまわってた覚えがあります。 さてAWSの障害発生率が低いといってもゼロというわけではありません。仮に0.1%だとしても1000日つまり3年運用していれば1回くらい障害に遭遇するものです。0.01%だったとしてもサーバーが1万台あれば1日1回なにかしらのトラブルに遭遇しても不思議ではありません。 トラブルに遭遇すると、当然サービスや処理に影響をきたしてしまうわけで早期の暫定処置と、その後に恒久的な対策が求められます。その時に重要なのは早く正しく原因を特定することです。トラブルシューティング力が重要です。 A
＠IT：壊れたパーティションを修復するには
パーティションがクラッシュすると、Linuxの起動とは関係ないパーティションであっても以下のようなメッセージが表示されることがある。 Checking root filesystem fsck.ext3/dev/hda5: : Bad magic number in super-block while trying to open /dev/hda5 （省略） *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Give root passwrd for maintenance (or type Control-D to continue):
XenServerのiSCSI共有ストレージが壊れた時の復旧方法メモ
トラブルの概要 先日、社内で使っているXenServerの共有ストレージにアクセス出来なくなると言うトラブルが起こった。 使っていた共有ストレージは、Buffalo TeraStation ProのiSCSIモデル。セットアップしてから約1年半、全く何のトラブルも無く動いていた機器だったので、油断していた。 ビルディングのメンテナンスで長時間の停電があって、その停電からの復帰後に起動したら「iSCSIの論理ボリュームを作成出来ない」という旨のエラーがストレージ側のログに出て、XenServerからの接続が一切出来なくなってしまった。 TeraStationの管理画面を開いて色々やって見たけれどもどうもらちが開かないので、TeraStationからHDDを取り出してPC（サーバー）に直接接続してみた。Raid1で4本のHDDを2本ずつ別々にミラーリングしているだけだったので、1本だけ取り出し
sanonosa システム管理コラム集: LinuxでLVMのデータを抜き出す方法
keyword: Linux,LVM,HDD,抜き出し 最近久しぶりにLinux(CentOS)をインストールする機会がありまして、いつの間にかLinuxにもLVM(論理ボリュームマネージャ)が導入されていることを知りました。LVMを使うとソフトウェアRAIDが組めたりパーティションのサイズを変えられたりできるので便利といえば便利です。が、最近ちょっとした事件がありました。オペミスでOSが死亡してしまい、データだけでも救出しようとしたときの話しです。旧来の方法であれば、別HDDにLinuxを入れて、OSが死亡したHDDのデータ用パーティションをmountすれば簡単にデータが抽出できたのですが、LVMだとちょっと面倒くさいです。そこで今回はLinuxでLVMのデータを抜き出す方法をまとめてみました。(今回は多分一部ケアレスミスが含まれていると思います。その場合ご指摘いただけたら幸いです) 【
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
